Hi,
I am building a Linux sync client on top of @protontech/drive-sdk and have two questions:
- What is the event log retention period for VolumeEventManager?
We're implementing event-based incremental sync using getEvents(eventId) to replace full remote tree walks at startup. If a client has been offline for several days, should it expect TreeRefresh and plan for a full-walk fallback? Knowing the retention window helps us set the right user expectation around fast
startup guarantees.
- Public key 429s on pre-2024 nodes
During reconciliation of large folders containing files created before 2024, the SDK fires a public key API request per node and hits HTTP 429. This causes a cascade of decryptionError metrics and a Failed to load some items error for the affected pair.
Is there a recommended pattern to avoid this — does the SDK have a public key cache, or is there a batch endpoint we should be using instead?
Hi,
I am building a Linux sync client on top of @protontech/drive-sdk and have two questions:
We're implementing event-based incremental sync using getEvents(eventId) to replace full remote tree walks at startup. If a client has been offline for several days, should it expect TreeRefresh and plan for a full-walk fallback? Knowing the retention window helps us set the right user expectation around fast
startup guarantees.
During reconciliation of large folders containing files created before 2024, the SDK fires a public key API request per node and hits HTTP 429. This causes a cascade of decryptionError metrics and a Failed to load some items error for the affected pair.
Is there a recommended pattern to avoid this — does the SDK have a public key cache, or is there a batch endpoint we should be using instead?