Closed
Conversation
Contributor
Author
|
the fix is redundant |
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.
An explanation for the strange behavior in dev:
The dev database has old data. When the tenant ID was changed from 00000-* to 12345-* (commit fd599e3), existing records in the dev DB still have tenant = '00000000-...'. Every query
filters by tenant:
So it finds zero rows — all existing dev data is invisible. Production likely got a fresh database after the change, or had a proper migration, so all its records were created with 12345-* from the start.
The "fix" of setting
AGENTLANG_DEFAULT_TENANT_ID=00000-*in dev is really just a workaround to match the stale data. The real fix option would be one of:UPDATE <tables> SET __tenant__ = '12345678-1234-1234-1234-123456789abc' WHERE __tenant__ = '00000000-0000-0000-0000-000000000000'