Summary
During the ReportsHQ migration from repeated native panels to the shared Card component, a rendering regression test found stale caller-derived content on a subsequent render. The component migration is intentionally uncommitted and unpushed pending a framework fix.
Observed environment
- Installed @stacksjs/stx: 0.2.401
- Installed @stacksjs/components: 0.2.401
- macOS, Bun
- Local template-rendering tests using synthetic fixtures only; no production account data or production requests were involved.
Expected behavior
Each render must reflect its current caller data, including conditional slot content. Reusing a component must not retain values or optional sections from an earlier rendering context.
Actual behavior
The initial account-panel fixture rendered correctly. A later fixture with changed display data and an absent optional date still contained the earlier values and date section. The new optional-content assertion failed. Earlier single-render checks passed, so those checks alone did not catch the problem.
The test exercises the real page markup through processDirectives and the installed Card implementation. Backend session lookup is excluded and explicit synthetic view data is supplied. This establishes a renderer-level correctness failure, not a verified production incident.
Investigation
The installed renderer implementation in dist/utils.js, renderComponentWithSlot, has a component-output cache used by components declaring a cached server script. Inspection indicates that cache identity does not adequately account for caller-derived slot output and its conditional dependencies. Please audit this boundary in the source implementation rather than applying an app-specific workaround.
Card is the observed case. Badge also opts into this renderer cache path, so the audit should cover other cached components; this report does not claim every component or production usage is affected.
Impact and scope
This blocks preserving behavior during shared-component adoption. Caller-dependent output must remain correct across renders. Where such content is request-specific, maintainers should additionally assess isolation implications privately; no production disclosure has been established or tested.
Suggested implementation sequence
- Define and enforce which component inputs and caller dependencies make cached output reusable.
- Prevent reuse when those dependencies differ or cannot be represented safely. Prefer a framework-level cache correctness fix over per-app cache disabling or artificial cache-busting props.
- Add regression coverage for successive renders with changing synthetic caller values, optional slot sections, and named/default slots.
- Cover cached components nested in loops and includes, along with client-bound slot content and component hydration metadata.
- Verify unchanged inputs still render correctly and assess performance after correctness is established.
- Publish a fixed version and document it so downstream applications can consume the fix and rerun their migrations.
Acceptance criteria
- Changed caller data produces current content, with no stale optional sections.
- Repeated renders remain isolated across distinct rendering contexts.
- Nested components, loops, and client bindings preserve their semantics.
- Regression tests fail on the affected implementation and pass after the fix.
- ReportsHQ can adopt Card without editing framework internals, disabling caching locally, or weakening its tests.
This is an issue report only. No upstream PR, release, merge, or deployment has been performed.