Do not treat effective-value scopes as stack settings - #22
Merged
Conversation
Wodby 1 exports some service configuration scopes for their effective value rather than as settings. The stack settings path skipped deployment and resources by name but converted everything else, so when implementation started arriving in that map it failed conversion and blocked the migration: "configuration value is not a supported scalar", once per instance pinning one. Replace the inline name check with a named predicate covering all three. The effect of implementation is already carried by the exported service version, and no consumer reads it, so skipping it loses nothing. Wodby 1 also stops exporting the value, but a Wodby 2 CLI meets Wodby 1 deployments that do not yet, and this is the layer that keeps a migration running against them. A genuinely unrepresentable setting still blocks; that is covered by its own test so the skip list cannot quietly become a way to lose real problems. Validation: go build ./..., go vet ./..., go test ./... (all packages pass). Tests use a template-reference value, the shape that actually failed.
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
1 participant
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.
Summary
Wodby 1 exports some service configuration scopes for their effective value rather than as settings.
preparedStackSettingsskippeddeploymentandresourcesby name and converted everything else, so whenimplementationbegan arriving in that map it failed conversion and blocked the migration:One per instance pinning an implementation. The value is a Wodby 1 template reference, not a scalar.
Fix
Replace the inline name check with a named predicate covering all three scopes. The effect of
implementationis already carried by the exported serviceversion, and no consumer readsConfiguration["implementation"]— so skipping it loses nothing.Why this layer matters independently. Wodby 1 also stops exporting the value, but a Wodby 2 CLI meets Wodby 1 deployments that do not yet. This is what keeps a migration running against them.
The skip list cannot quietly swallow real problems. A genuinely unrepresentable setting still blocks, covered by its own test.
Validation
go build ./...,go vet ./...,go test ./...— all packages pass.Tests use a template-reference value — the shape that actually failed. The earlier test used a plain string, which is why this got through.