Skip to content

fix: recreate the pod when inline content changes - #22

Open
blarghmatey wants to merge 1 commit into
marimo-team:mainfrom
mitodl:fix/content-change-recreates-pod
Open

blarghmatey wants to merge 1 commit into
marimo-team:mainfrom
mitodl:fix/content-change-recreates-pod

Conversation

@blarghmatey

Copy link
Copy Markdown

Summary

Editing spec.content on a running MarimoNotebook updates the ConfigMap, but the pod keeps serving the old notebook. The pod spec only names the ConfigMap, so PodSpecHash doesn't change, and the copy-content init container copied the previous file into the notebook volume when the pod started.

This adds a marimo.io/content-hash annotation to content-mode pods and folds it into PodSpecHash. A content change now recreates the pod, the same way an env or image change already does. Source-mode pods get no annotation and hash exactly as before; a unit test pins that. Content-mode pods created by an older operator are recreated once after upgrading, because their stored hash didn't include the content.

The new envtest case ("should recreate Pod when inline content is changed") times out on main and passes with this change.

Checklist

  • Any AI-generated code has been reviewed line-by-line by the human PR author.
  • Tests have been added or updated for the changes (where applicable).
  • make lint and make test pass locally (operator).
  • uv run pytest and uv run ty check kubectl_marimo pass locally (plugin). (Not applicable, the plugin is unchanged.)
  • If CRD fields changed, make manifests has been run and generated files are committed. (No CRD change.)
  • Documentation updated where relevant. (No user-facing docs describe this behavior.)

https://claude.ai/code/session_01Mznd5RYgzKGBShstpLnoFQ

Editing spec.content updated the ConfigMap but left the pod running the
old notebook. The pod spec only names the ConfigMap, so the spec hash did
not change, and the copy-content init container had already copied the
previous file into the notebook volume.

Content-mode pods now carry a marimo.io/content-hash annotation, and
PodSpecHash folds it in, so a content change recreates the pod the same
way an env or image change does. Source-mode pods have no annotation and
hash exactly as before. Content-mode pods created by an older operator
are recreated once after upgrading, because their stored hash did not
include the content.

Claude-Session: https://claude.ai/code/session_01Mznd5RYgzKGBShstpLnoFQ
Copilot AI balanced review requested due to automatic review settings October 1, 2026 20:34

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot review overview

🟢 Approval recommended

The implementation addresses stale inline content with focused, compatible change detection and appropriate tests.

Review effort: Balanced
Findings: None

What changed in this PR

Ensures inline notebook content updates trigger pod recreation so the init container copies the latest content.

Changes:

  • Adds content hashes to content-mode pods and pod change detection.
  • Adds unit and controller reconciliation coverage.
  • Preserves existing source-mode hashes.
File Description
pkg/​resources/​pod.go Incorporates inline content into pod hashing.
pkg/​resources/​pod_test.go Tests content and source-mode hashing.
internal/​controller/​marimonotebook_controller_test.go Tests recreation after content updates.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants