Repository navigation
Fix Integration Data Updater apiReference filter - #1961
Conversation
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
🟢 Approval recommended
The narrow fix preserves the required filtering behavior, with direct regression coverage and CI integration; no blocking issues remain.
No open issues 🎉
What changed in this PR
Fixes #1960 by preventing the Integration Data Updater from reading missing apiReference metadata under PowerShell strict mode.
Changes:
- Includes catalog entries with omitted or explicit
truemetadata and excludes explicitfalse. - Adds regression coverage that executes the production predicate against fixtures and the real catalog.
- Runs the regression in the Tools Tests workflow.
| File | Description |
|---|---|
tests/PackageJsonGenerator.Tests/generate-package-json.Tests.ps1 |
Tests the production filter under strict mode. |
src/tools/PackageJsonGenerator/generate-package-json.ps1 |
Checks property existence before reading optional metadata. |
.github/workflows/tools-tests.yml |
Adds the PowerShell regression test to CI. |
Review effort: Balanced
Frontend HTML artifact readyThe latest frontend build uploaded the This comment updates automatically when a new frontend build artifact is uploaded. |
|
CI update: the change-specific checks pass, including Tools Generator Tests, frontend validation, both CodeQL analyses, AppHost build, and frontend build. The required gate is currently blocked by all six Playwright shards timing out in existing API navigation/search tests; the same desktop E2E check is also failing on open PRs #1958 and #1955, and this PR does not change frontend code. Representative failure: https://github.com/microsoft/aspire.dev/actions/runs/40508362949/job/122207506451 🤖 Posted by Repository agent (AI Agent) |
## Summary Include deployment metadata in API reference cache keys, using the same commit and normalized repository URL as the shared page head. Preserve same-deployment cache reuse and the existing deployment guard. The representative `api-cross-language-navigation.spec.ts:46` failure (`window.__apiNavigationLoaded`: expected `true`, received `undefined`) is caused by mixed deployment identities, not an insufficient assertion timeout: - [Main desktop shard](https://github.com/microsoft/aspire.dev/actions/runs/40395504687/job/121831716616), SHA `b5b1becb58cb452a533b80d585d94510a99a467e`. - [Updater #1961 desktop shard](https://github.com/microsoft/aspire.dev/actions/runs/40508362949/job/122207506451), PR head `def401a825443769dea52689eab5793bbb4d7d38`. Both downloaded traces, including their first attempts and two internal retries, contain an API landing page with `git-commit-id=b5b1becb58cb452a533b80d585d94510a99a467e` and a restored Redis package page with `git-commit-id=43e5933e8d41e6f0f0d84eb785943727eb946dff`. The deployment guard correctly forces a document navigation and clears the in-memory marker. Both pages have the ClientRouter opt-in. Bun resolves the build environment outside Astro's template dependency hash. The existing document-only key therefore permits stale head metadata to survive a warm incremental build. Adding the missing output dependency regenerates API pages when deployment metadata changes; it does not disable incremental reuse globally. This is independent of #1961's updater/StrictMode repair. No updater, deployment-guard, browser assertion, workflow, timeout, retry, or coverage changes. ## Third-party links and affiliations None. Test-only example repository URLs are fixtures, not third-party links or affiliations. ## Validation - `bun run lint`: passed, including skill-digest verification and zero-warning ESLint. - `bun run test:unit`: 82 files passed; 1,108 tests passed, one existing test skipped. Five new cache-key regression tests cover deployment changes, repository changes/normalization, unchanged-data reuse, owning-package paths, and shared head fallbacks. - Real-site Playwright, desktop Chromium, one worker: both existing targeted tests passed: “API landing searches and query filters survive language changes and history navigation” and “all six API search surfaces cancel pending input when leaving, including non-API destinations”. - Isolated two-page Astro 7.4.1 production fixture, Bun 1.4.3, actual deployment guard and ClientRouter: the byte-identical baseline cache helper restores old metadata after sequential identity A/B builds; 30/30 controlled navigations reproduce hard reloads. - Fixed helper, identical fixture/data: sequential identity A/B builds update both pages; repeating identity B restores the keyed page. All 30/30 navigations preserve the session and back history (five repetitions each across desktop/tablet/mobile, with native transitions and forced fallback). - [Full production CI](https://github.com/microsoft/aspire.dev/actions/runs/40805377771) passed at head `7bd82d0985b1bed59b455b0235c4c2160cfcd3f2`: all six browser shards, merged report, frontend gate, and required `ci-gate` are green. Browser logs show 1,390 first-attempt passes and 95 existing skips across 1,485 registered cases, with no failed attempts or internal retries. The original navigation assertion and related query/history test pass on desktop, tablet, and mobile. Existing same/changed/missing-deployment guard tests remain green. - Production Node 24.x lint/unit validation confirms 82 files passed, 1,108 tests passed, and one existing skip, including all five new cache-key regressions. - Production build: Astro reports 32,203 pages in 5m44s. It restored a compatible base cache, regenerated 24,059 logged API HTML routes, and retained 534 OG restores. This initial key-implementation change necessarily regenerates API HTML; it is not a steady-state overhead measurement. The exact-base cold build took 7m48s, but differing cache/runner state prevents a patch-only performance comparison. - Verified the actual production artifact's SHA-256 digest and four C#/TypeScript landing/Redis HTML samples: all share deployment/source-link commit `1a916aa5b5fd6cb8a02e5c75eedaead2d61a5263` and ClientRouter opt-in. The build intentionally uses the effective base/merge-base identity, not the PR head SHA. Local browser/unit tooling used Node 26.12.1; production validation used CI's Node 24.x and pinned Bun 1.4.3. No full-site production build or full production browser matrix was run locally, per repository guidance; the production CI matrix above supplies that qualification. Controlled fixture repetitions and this single clean CI run are not a repository-wide flake-rate estimate. Authorized-human review is still required. **🤖 Posted by AspireAgent (AI Agent)** Co-authored-by: davidfowl <95136+davidfowl@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Project docs review: not applicableReviewed the changed-file list and diff for head Phase A - claims: No documentation prose, examples, or Aspire API claims were added or changed. The three changed files are the PowerShell generator, its regression test, and the tools-test workflow. No upstream source verification applies. Phase B - doc tester: Not applicable: no affected documentation routes or sections to exercise. No docs server, unrelated page tests, or site build was run. This is a docs-applicability result, not a claim that documentation was browser-tested. The applicable code review follows separately. This Project stage is recorded once for the PR, not per commit. |
Project code review: no actionable findingsReviewed all three changed files at The property-existence guard short-circuits the missing Test coverage and evidence:
CI limit: The latest returned checks for this exact head still show failed frontend E2E shards and failed frontend/CI gates. This narrow review does not establish their cause or baseline equivalence and does not declare the PR green or merge-ready. Conversation-comment report only; no formal approval or request-changes review. This Project stage is recorded once for the PR, not per commit. |
docs-pr-reviewer report — [partial — phase A: key claims evaluated; phase B: not run (docs site was not served in this automated run)]Recommendation: needs human Source used: n/a — repository CI/tooling ( Phase A — claims
Phase B — doc-testerNot run; rendering of the changed pages is not browser-checked. 🤖 Posted by aspire.dev - squad (AI Agent) |
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
…m in one issue (#2047) ## Summary Follow-up to #1961. After its fix, the Integration Data Updater gets past `apiReference` but aborts because 3 CommunityToolkit packages (`Hosting.Chroma`, `Hosting.Keycloak.Extensions`, `Hosting.Kind` at `17.0.0-beta.994`) depend on `Aspire.Hosting >= 17.0.0-preview.1.26552.6`, which is not on nuget.org (NU1102). One failing package blocked every data update. - `generate-package-json.ps1`: a failed package no longer exits 1 or deletes the staged output; its existing generated files are kept instead of being removed as stale. - `update-integration-data.ps1`: C# and TypeScript package failures warn and continue; failing package names are emitted as the `api_failures` output and listed in the PR body. - `update-integration-data.yml`: new "Track API generation failures" step maintains a single issue. Its body lists the current failing packages; a comment is added only when that set changes, and the issue closes when nothing fails, so identical failures never create duplicates. ## Third-party links and affiliations None. ## Validation - PowerShell parser on both scripts: 0 errors. - `generate-package-json.Tests.ps1`: passed (209 included, 1 excluded). - Full updater and the issue step were not run; run `workflow_dispatch` after merge. Semantic validation for packages kept at old data is unverified. --------- Co-authored-by: David Pine <7679720+IEvangelist@users.noreply.github.com> Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Summary
Fixes #1960.
The Integration Data Updater has failed since #1895 because
generate-package-json.ps1reads optionalapiReferencemetadata directly underSet-StrictMode -Version Latest. The catalog omits the property for 209 of 210 entries, so generation aborts before processing packages.apiReference.trueentries; exclude explicitfalse.Failure evidence: first affected run, latest inspected failure. Related prior repairs: #1813 and #1899; stale rolling updater PR: #1737.
Validation
209 included, 1 excluded.PackageJsonGenerator.Tests: 41/41 passed.AtsJsonGenerator.Tests: 37/37 passed.update-integrations.vitest.test.ts: 50/50 passed.update-integration-data.ps1: 0 errors.actionlint .github/workflows/tools-tests.yml: passed.git diff --check: passed.Limitations
A complete updater
workflow_dispatchwas not run becausemainstill contains the failing predicate; running it before this fix lands would reproduce the known failure and cannot validate the branch change. The PR's Tools Tests exercise the exact production predicate, and the next post-merge manual/scheduled updater run should provide end-to-end confirmation.🤖 Posted by Repository agent (AI Agent)