feat: scaffold PIC-1321 App Framework storage for Klaviyo field mappings - #11280
feat: scaffold PIC-1321 App Framework storage for Klaviyo field mappings#11280david-shibley-contentful wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
⚔️ I think we are exposing a bit too much about the innerworkings of app storage in this ADR. The idea was to use it for internal apps only.
There was a problem hiding this comment.
Good call — removed the ADR entirely in eab1588, nothing else in the codebase referenced it. Updated the PR description to drop the dangling link too.
| // the same fallback logic in entrySyncFunction.ts. | ||
| function toStorageRow(mapping: any): FieldMappingRow | null { | ||
| const contentfulFieldId = mapping.contentfulFieldId || mapping.id; | ||
| const klaviyoBlockName = mapping.klaviyoBlockName || mapping.name || contentfulFieldId; |
There was a problem hiding this comment.
💭 I think we are doing this in entrySyncFunction.ts as well the contentfulFieldId/klaviyoBlockName/fieldType alias fallback in toStorageRow is basically the same logic. Perhaps this could be a shared helper both files import?
| { parameters: { entryId, mappings } } | ||
| ); | ||
| } catch (error) { | ||
| logger.error('Error writing field mappings via Set Field Mappings action:', error); |
There was a problem hiding this comment.
💭 Do we want to surface this failure to the caller somehow? Right now if the App Action call fails we just log and return none of the four call sites (ConfigScreen, FieldMappingScreen, FieldSelectDialog, Sidebar) can tell the save didn't go through.
Adds a storage block to contentful-app-manifest.json, a local type shim for the not-yet-shipped context.storage DSL, and getFieldMappings/ setFieldMappings Functions written against that contract. Get/set now try context.storage first and fall back to the existing klaviyoFieldMappings CMA-entry logic (moved to field-mappings-legacy.ts) when it's absent, which is true in every real environment today. The frontend no longer touches that CMA entry directly - it calls the two App Actions via field-mappings-client.ts, same exported names/ signatures as before so call sites only changed their import path. getFieldMappings also bulk-migrates the legacy blob into the field_mappings storage table the first time context.storage is present, gated on the table being empty so it only runs once. entrySyncFunction.ts still reads via the legacy path unconditionally; wiring it onto context.storage is a follow-up once the platform ships. Known risk: the manifest change is confirmed safe against the local @contentful/app-scripts@2.3.0 build validation, but it's unverified whether the live Extensibility API's bundle-upload validation accepts the new top-level storage key. Do not run upload-ci/upload-staging/ deploy with this change until that's confirmed against staging. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
eab1588 to
2bc0d32
Compare
Summary
storageblock incontentful-app-manifest.json, a local type shim for the not-yet-shippedcontext.storageDSL, and two new Functions (getFieldMappings,setFieldMappings) written against that contract.entrySyncFunction.tsand the existing frontend field-mapping UI (which currently store mappings as a stringified JSON blob in aklaviyoFieldMappingsCMA entry, per the drift from ADR-0003) are untouched.@contentful/app-scripts@2.3.0build validation, but it's unverified whether the live Extensibility API's bundle-upload validation accepts the new top-levelstoragekey. Do not runupload-ci/upload-staging/deploywith this change until that's confirmed against staging.Test plan
npm run build:functionssucceeds locally with the new manifeststorageblock and both new Functions bundle cleanlynpx tsc --noEmitpasses with no type errors against the installed@contentful/node-apps-toolkit@3.15.0npm testrun (no existing test files touch these new files; pre-existing suite has zero test files, so this is a no-op check)storagekey before ever runningupload-ci/deployon this branchGenerated with Claude Code