feat(dashboards): Store dashboard snapshot on PUT when revisions flag is enabled#113065
Open
feat(dashboards): Store dashboard snapshot on PUT when revisions flag is enabled#113065
Conversation
… is enabled When the organizations:dashboards-revisions feature flag is enabled, the dashboard PUT endpoint now serializes the current dashboard state (using the existing DashboardDetailsModelSerializer) into a DashboardRevision before writing the new version. The snapshot and the save are wrapped in the same transaction so a failed update rolls back the revision too. Serialization is intentionally done outside the transaction to avoid making hybrid-cloud RPC calls (user_service.serialize_many) inside an atomic block. Revisions beyond the 10 most recent are deleted after each save to bound storage growth. Refs DAIN-1516 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
github-actions
bot
added
the
Scope: Backend
…unctions Move snapshot creation and pruning out of the put() method into two dedicated functions, _take_dashboard_snapshot and _save_dashboard_revision, to keep the request handler focused on HTTP concerns. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…n.create_for_dashboard The retention policy and schema version are model-level concerns — moving them out of the endpoint and into a classmethod on DashboardRevision makes the logic reusable from any callsite without duplicating the pruning rules. The endpoint retains _take_dashboard_snapshot, which owns the API-layer concerns: feature flag check and serialization via DashboardDetailsModelSerializer. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Pruning and field-correctness tests for DashboardRevision.create_for_dashboard now live in test_dashboard.py, tested directly without going through HTTP. The endpoint tests are trimmed to only verify the endpoint wires up to the model correctly — they no longer re-test the model's own behaviour. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…rd call site Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Contributor
|
Looks good, a couple questions:
|
…on fails If serialize() raises (e.g. user_service RPC failure), the exception was propagating before the transaction block and causing the entire PUT to fail. The revision snapshot is secondary to the save; catch and log the exception so the dashboard update always proceeds. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Contributor
Author
There's a race condition - between taking the snapshot and entering the transaction, another user could save the dashboard — so the snapshot we store might not accurately reflect the state just before our save.
We're using the model serializer, used for dashboard api responses. This makes the preview endpoint simple, with more work on the restore endpoint to map it back to a model.
I've added a new commit to log an error if serialize fails, since it's not as critical as saving the new dashboard record. |
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
2 participants
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.
When the
organizations:dashboards-revisionsfeature flag is enabled, the dashboard PUT endpoint now creates aDashboardRevisionsnapshot of the current dashboard state before writing the new version, enabling history and revert functionality.The snapshot is produced by the existing
DashboardDetailsModelSerializer(the same serializer used by the GET endpoint), so it captures the full pre-edit state including all widgets and their queries.A few implementation notes worth calling out:
transaction.atomicblock.DashboardDetailsModelSerializercallsuser_service.serialize_manyfor thecreatedByfield, which is a hybrid-cloud RPC call that cannot run inside a transaction. TheDashboardRevision.objects.createitself stays inside the transaction, so a failed save rolls back the revision too.Refs DAIN-1516