Hi everyone,
We are preparing the production migration of a monday Code Marketplace app and have reached a few platform-level questions where we cannot find an explicit supported contract in the documentation.
We already have support requests open, but these questions seem general to monday Code / Apps Framework development rather than specific to our account, so I’m posting them here as one topic.
Our goal is to build a fail-closed migration without relying on undocumented assumptions.
------------------------------------------------------------
1. SecureStorage recovery after a lost write acknowledgement
------------------------------------------------------------
Consider this sequence:
1. The app calls:
secureStorage.set(key, value)
2. The write may have completed successfully.
3. The monday Code process terminates or the response is lost before the app receives the acknowledgement.
4. A replacement process must reconcile the operation.
What is the supported application-level contract?
- Is secureStorage.get(key) read-after-write consistent across replacement monday Code processes?
- If get(key) returns not-found after an ambiguous set(), can that be treated as authoritative proof that the original set did not commit?
- Could the original set still complete after that not-found read?
- Is repeating set() with the exact same key and exact same value a supported idempotent recovery operation?
- Does set() atomically replace the value for an existing key?
- Is there a supported way to know that the original ambiguous operation has completely finished/drained and can no longer commit later?
Our current implementation intentionally does not interpret timeout, elapsed time or not-found as proof of absence unless monday documents that guarantee.
An exact authenticated readback is treated as proof of presence.
------------------------------------------------------------
2. Object Storage recovery after a lost upload acknowledgement
------------------------------------------------------------
We have the equivalent problem with:
uploadFile(fileName, bytes)
If the upload may have succeeded but the process loses the response:
- Are getFileInfo(fileName) and downloadFile(fileName) read-after-write consistent across replacement monday Code processes?
- If the object is reported as missing, is that authoritative proof that the previous upload did not commit?
- Could the original upload become visible later?
- What happens when uploadFile() is called again with the exact same filename?
- atomic overwrite?
- rejection?
- another stored object?
- Is retrying the same filename with identical bytes a supported idempotent recovery pattern?
- Is etag intended to be a stable identity for the exact stored object bytes?
- What supported observation proves that the original ambiguous upload has fully drained and can no longer recreate/change the object after application-side erasure?
Our application can already verify presence using deterministic object names, expected metadata, file size and exact downloaded-byte hashes.
What we are missing is the supported contract for authoritative absence and original-operation drain.
------------------------------------------------------------
3. Already-open old app clients writing to monday.storage
------------------------------------------------------------
We are also migrating PII-capable data away from legacy/global monday.storage.
We can patch the current Live app so that newly loaded clients stop using the old storage path.
However, what about an iframe/tab that was already open and still has the older JavaScript loaded?
When a newer app version becomes Live and the previous one becomes Deprecated:
- Can the already-open iframe continue running its previously loaded JavaScript?
- Can it continue calling monday.storage.setItem()?
- Is there a supported mechanism to force reload, invalidate, terminate, revoke or otherwise fence such an old client?
- Can the backend or Developer Center revoke its ability to write to global monday.storage?
- If no hard revocation exists, what migration/drain procedure does monday recommend when an app must move PII out of legacy monday.storage?
A backend maintenance flag cannot by itself stop a cached frontend from calling monday.storage directly, so we do not want to select a new secure storage authority while an old writer could still reintroduce private data into the legacy store.
------------------------------------------------------------
4. PII contained inside uploaded files in Object Storage
------------------------------------------------------------
The Object Storage documentation describes Object Storage as the monday Code storage mechanism for documents/files.
Marketplace privacy guidance also requires PII handled by monday Code apps to use Secure Storage.
How should this requirement be interpreted for the actual bytes of user-uploaded documents that may themselves contain PII?
Is this architecture supported?
- file bytes -> monday Code Object Storage
- identifying metadata -> SecureStorage
- opaque structural reference -> Document DB
If raw PII-containing file bytes should not be stored directly in Object Storage, would the following be considered compliant?
- application-side authenticated encryption, e.g. AES-256-GCM / equivalent AEAD
- encrypted ciphertext -> Object Storage
- encryption key / wrapped DEK -> SecureStorage
- identifying metadata -> SecureStorage
- opaque reference -> Document DB
Would application-encrypted ciphertext in Object Storage satisfy the Marketplace PII requirement?
If not, what monday-native storage pattern is recommended for customer documents that can be tens of MB in size and may contain PII?
------------------------------------------------------------
Why we are asking
------------------------------------------------------------
Our recovery and migration logic is deliberately fail-closed:
- exact authenticated SecureStorage readback => presence proven
- exact ObjectStorage bytes/hash => presence proven
- timeout => not proof of absence
- elapsed time => not proof of absence
- missing read => currently not proof of absence
- unresolved writer => erasure remains blocked
- old storage authority is not selected until old writers are proven excluded/drained
We are not looking for internal implementation details.
We need to understand the supported application-level behavior that monday developers and Marketplace apps may safely rely on.
If someone from the monday Code / Apps Framework / storage team can clarify these guarantees, that would be extremely helpful — and I suspect useful for other developers implementing robust migrations and crash recovery as well.
Thanks!