Repository navigation
HOTFIX: main is red — restore the using MeshOperations needs - #2411
Merged
Merged
Conversation
`Build solution` fails on main at c753ad2: memex/Memex.Portal.Shared/Api/MeshApiEndpoints.cs(335): error CS0246: The type or namespace name 'MeshOperations' could not be found A semantic conflict, not a textual one — which is why every PR run was green solo. #2283 moved MeshOperations to namespace MeshWeaver.Mesh and updated this call site's `using` to match. #2397 (the #2370 fix) then restored the ORIGINAL namespace MeshWeaver.AI, because the type is reached by already-published modules through [assembly: TypeForwardedTo] and a forwarder CANNOT rename. Each change compiles against the main it was branched from; only the combination fails, and no PR run built that combination. One line: the file gets `using MeshWeaver.AI;` back. Its sibling `Memex.LocalMesh/LocalMeshApiEndpoints.cs` already had it, which is why exactly one file broke and why the fix is this small. I checked every .cs referencing MeshOperations rather than assuming this was the only one. Also leaves a note at the using: the type lives in ASSEMBLY MeshWeaver.Mesh.Operations but keeps NAMESPACE MeshWeaver.AI, and that mismatch is deliberate and permanent. Tidying the using to match the assembly name is exactly what broke main. Chose the fix over reverting #2397 because that revert would drop a live production fix (a TypeLoadException on every MCP tool call) plus the gate that detects the whole class — and the agreed criterion is main green on the very next run, which one line achieves. Verified: Memex.Portal.Shared builds clean under -c Release -warnaserror. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Restores the correct MeshOperations namespace import in the Memex portal REST API endpoints, fixing the CS0246 break on main caused by the namespace/assembly mismatch required for TypeForwardedTo-based binary compatibility.
Changes:
- Re-adds
using MeshWeaver.AI;soMeshApiEndpointscan resolveMeshOperationsagain. - Adds an explicit header comment documenting why
MeshOperationsremains in theMeshWeaver.AInamespace even though it lives in theMeshWeaver.Mesh.Operationsassembly (to prevent “tidy-up” regressions).
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Contributor
Test Results (shard 3) 9 files 9 suites 4m 48s ⏱️ Results for commit c01ed69. |
Contributor
Test Results (shard 0)620 tests 616 ✅ 17m 47s ⏱️ Results for commit c01ed69. |
Contributor
Test Results (shard 5) 9 files 9 suites 7m 8s ⏱️ Results for commit c01ed69. |
Contributor
Test Results (shard 2)2 878 tests 2 775 ✅ 8m 11s ⏱️ Results for commit c01ed69. |
Contributor
Test Results (shard 1)2 036 tests 1 843 ✅ 9m 28s ⏱️ Results for commit c01ed69. |
Contributor
Test Results (shard 4)2 195 tests 2 193 ✅ 15m 18s ⏱️ Results for commit c01ed69. |
Contributor
rbuergi
added a commit
that referenced
this pull request
Aug 26, 2026
rbuergi
added a commit
that referenced
this pull request
Aug 26, 2026
The branch predated the three fixes that unbroke main, so its build failed on a CS0246 in Memex.Portal.Shared that this diff cannot reach.
This was referenced Aug 26, 2026
rbuergi
added a commit
that referenced
this pull request
Aug 28, 2026
#2349 removed `using MeshWeaver.AI;` from MeshApiEndpoints as a phantom, and main went red with CS0246. Two fixes then restored it independently — #2408 added it under a banner comment at the top of the file, #2411 added it again inline further down with its own explanation. Both landed, so main now carries the SAME using twice and fails CS0105 under warnings-as-errors. The type genuinely needs it: MeshOperations ships in assembly MeshWeaver.Mesh.Operations but keeps namespace MeshWeaver.AI, frozen by the TypeForwardedTo contract in #2370. So this keeps ONE directive and folds both explanations into the banner that sits directly above it, including why it looks removable and the fact that removing it has now cost three red-main incidents. One directive, one explanation, kept together — the two split copies are exactly how the second restore could not see the first. Verified: Memex.Portal.Shared builds clean.
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
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.
Main is red
Run 32994185103 on
c753ad2f5. CD refuses a red tip, so the surface-manifest image is hard-blocked behind this.A semantic conflict — which is why every PR run was green
MeshOperationsto namespaceMeshWeaver.Meshand updated this call site'susingto match.MeshWeaver.AI, because already-published modules reach the type through[assembly: TypeForwardedTo]and a forwarder cannot rename.Each compiles against the main it was branched from. Only the combination fails, and no PR run built the combination — the 17:05 merge burst produced it.
The fix: one line
using MeshWeaver.AI;returns to the file. Its siblingMemex.LocalMesh/LocalMeshApiEndpoints.csalready had it, which is why exactly one file broke; I checked every.csreferencingMeshOperationsrather than assuming.I also left a note at the
using, because the shape invites a "tidy-up" that re-breaks it: the type lives in assemblyMeshWeaver.Mesh.Operationsbut keeps namespaceMeshWeaver.AI, deliberately and permanently.Why not revert #2397
Reverting would drop a live production fix (a
TypeLoadExceptionon every MCP tool call) and the gate that detects the whole class. The agreed criterion is main green on the very next run, and one line achieves that.Verification
Memex.Portal.Sharedbuilds clean under-c Release -warnaserror.🚨 Note the gate that would have caught this is #2407, still open: it makes a binary-compat failure block the merge. It would not have caught this particular break (a semantic conflict between two merges is a different class from a binary break), but it is the same family — a green solo run proving less than it appears to.
🤖 Generated with Claude Code