fix: persist published templates without runtime setup#4177
fix: persist published templates without runtime setup#4177orange-dot wants to merge 13 commits intosuperplanehq:mainfrom
Conversation
Signed-off-by: Bojan Janjatović <bojan.janjatovic@mamut-studio.com>
|
👋 Commands for maintainers:
|
Signed-off-by: Bojan Janjatović <bojan.janjatovic@mamut-studio.com>
Signed-off-by: Bojan Janjatović <bojan.janjatovic@mamut-studio.com>
fdb6744 to
3397b3c
Compare
Signed-off-by: Bojan Janjatović <bojan.janjatovic@mamut-studio.com>
0a50d54 to
4133d20
Compare
Signed-off-by: Bojan Janjatović <bojan.janjatovic@mamut-studio.com>
Signed-off-by: Bojan Janjatović <bojan.janjatovic@mamut-studio.com>
Signed-off-by: Bojan Janjatović <bojan.janjatovic@mamut-studio.com>
Signed-off-by: Bojan Janjatović <bojan.janjatovic@mamut-studio.com> (cherry picked from commit 1e1fea623386a541c83fc6b7dbe6953a33e5da44)
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 7536544. Configure here.
| pbCanvas, | ||
| autoLayout, | ||
| ) | ||
| } |
There was a problem hiding this comment.
Unused parameters silently ignored after refactor
Low Severity
CreateCanvas still accepts encryptor, authService, and webhookBaseURL parameters, but after the refactor these are completely unused — the function simply delegates to CreateCanvasWithAutoLayoutAndUsage without forwarding them. The gRPC service layer (CanvasService.CreateCanvas) continues to pass real service instances for these parameters, giving the false impression they participate in canvas creation. This dead parameter surface is misleading for future maintainers and carries unnecessary import dependencies on crypto and authorization packages solely for the function signature.
Triggered by project rule: SuperPlane — Bugbot (repository-wide)
Reviewed by Cursor Bugbot for commit 7536544. Configure here.


Summary
This is a narrow backend correctness fix for template-backed canvas creation. It preserves the published-template path while restoring the expected
InvalidArgumenterror semantics for the auto-layout failure case.Why
On the current path, a template auto-layout failure can escape with the wrong gRPC status even though the caller-level failure is still an invalid input/configuration condition. This makes the published-template flow harder to reason about and weakens the contract at the API boundary.
What changed
codes.InvalidArgumentat the create-canvas boundaryScope guardrails
Validation
superplane_testDB recreate plus schema/data migrationsdocker compose -f docker-compose.dev.yml run --rm --no-deps -e DB_NAME=superplane_test app go test ./pkg/grpc/actions/canvases -run 'TestCreateCanvasTemplateSkipsSetupValidationForOrgSpecificIntegrationNodes|TestCreateCanvasTemplateAutoLayoutReturnsInvalidArgument' -count=1 -p 1docker compose -f docker-compose.dev.yml run --rm --no-deps -e DB_NAME=superplane_test app go test ./pkg/grpc/actions/canvases -run 'TestCreateCanvas' -count=1 -p 1Observed results:
TestCreateCanvas*slice passedRequest for review
Would appreciate confirmation that this is the right place to preserve the published-template flow while restoring the
InvalidArgumentcontract for the template auto-layout path.