fix(export): use extensionName for services schema prefix instead of metaExtensionName#827
Merged
pyramation merged 1 commit intomainfrom Mar 16, 2026
Merged
Conversation
…metaExtensionName The metaReplacer in exportMigrationsToDisk was using metaExtensionName (e.g. 'agent-db-services') as the schema prefix for the services package, producing incorrect schema names like 'agent_db_services_auth_public'. The services metadata INSERT statements reference the actual deployed schemas which are owned by the application package and use its prefix (e.g. 'agent_db_auth_public'), not the services package prefix. Fix: Add an optional 'schemaPrefix' parameter to makeReplacer. When provided, schema names use this prefix instead of 'name'. The metaReplacer now passes extensionName as schemaPrefix, so: - Extension name replacement: 'constructive-extension-name' -> metaExtensionName (correct) - Schema prefix replacement: uses extensionName (correct) This is backward compatible - existing callers that don't pass schemaPrefix work exactly as before. For constructive-db where schemas are already named 'constructive_*', the replacer produces the same output since extensionName='constructive' matches the existing prefix.
Contributor
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
fix(export): use extensionName for services schema prefix
Summary
Fixes a schema naming bug in
exportMigrationsToDiskwhere the services/meta package replacer usedmetaExtensionNameas the schema prefix instead ofextensionName.Before: Exporting an app named
agent-dbwith services namedagent-db-servicesproduced incorrect schema references in the services SQL:After: Services metadata correctly references schemas owned by the application package:
The fix adds an optional
schemaPrefixparameter tomakeReplacer. When provided, schema names use this prefix instead ofname. Thenameparameter still controls theconstructive-extension-name→ extension name replacement (so the services package name is preserved correctly). This is fully backward compatible — callers that don't passschemaPrefixbehave identically to before.Why constructive-db wasn't visibly affected: constructive-db's
renameSchemas()pre-renames DB schemas toconstructive_*before export, andextensionNameisconstructive. So the metaReplacer's replacementconstructive_auth_public→toSnakeCase('constructive-services_auth_public')=constructive_services_auth_publicdoes technically produce the wrong output — but this may have been masked by other factors (e.g.,skipSchemaRenaming: truein the RLS path, or the services package not being re-exported recently).Review & Testing Checklist for Human
generate:constructiveor equivalent) and confirm the services package still hasconstructive_auth_public(notconstructive_services_auth_public). This is the highest-risk regression path.constructive-extension-namereplacement still works: Thenameparam (=metaExtensionName) is still used for the literal string replacement. Check that the services package's control file and metadata still reference the correct services extension name (not the app name).run-export.tsagainst a provisioned agent-os database with the updated@pgpmjs/coreand confirm schema names inpackages/agent-db-services/deploy/migrate/useagent_db_auth_public(notagent_db_services_auth_public).Notes
run-export.ts) that can be removed once this fix is published