Repository navigation
Content-node specs that fail on wrong code; Java's index failures - #576
Merged
Merged
Conversation
From the review of 20 Oct (spec 006). The stand-ins for graph-core's lazy
loads answered any query naming the relationship, so a load in the wrong
direction, or of another object, passed; they now answer by type,
direction and the dbId asked for, read from the query (directions as
domain-snapshot.json gives Java's model). /query/{id}/stId and
/normalPathway are held to naming the attribute as the request spelled it.
Each shown failing under the mutation it exists to catch.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
From the review of 20 Oct (spec 006). Each shown failing under the
mutation it exists to catch.
- /query/ids and /ids/map: a test where objects are found -- /ids in the
HashSet order, /ids/map keyed by the ids as sent in the HashMap order
(read from the text: JSON.parse moves a numeric key first). Writing
either in the order sent now fails.
- Nine of Java's 500s on the Solr paths were checked by status alone;
each now names Java's NullPointerException answer, so one answered as
a plain Solr failure fails.
- Stand-ins that answered any query now answer only the query the service
writes: the diagram-search object check (hasDiagram), the species by
exact name, the release (releaseNumber), discover's load (whole text).
- /citation/pathway/{id} cited end to end: a pathway by its DOI, a
reaction by its page, both by the id as given; /citation/export's three
formats each with their type and extension.
- /references/mapping/{identifier}'s query pattern is anchored at the end;
/search/query's targetResults are held in Java's order, not merely
present; the no-report check waits on a later report, not 50ms.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The review of this branch found four places answering Java's
NullPointerException text where Java throws an
ArrayIndexOutOfBoundsException, which GlobalExceptionHandler answers with
its own message (handleUnclassified), as node already does for the
measured "Index 0 out of bounds for length 0": an occurrence of fewer
than four parts (extractRawOccurrence, for /diagram/{d}/occurrences and
/diagram/{d}/flag; fireworksFlagging for /fireworks/flag) and an icon
entity of fewer than four parts. Each now names the index Java reads
first past the end, in the order search-core's bytecode reads them
([0],[2],[3],[1]; [0],[3]; [0]..[3]); fromSolr answers a javaMessage as
Java's 500. The spec this branch had pinned to the wrong message is
corrected, and each site has a test (all four fail on the code before).
- /fireworks/flag with two Species of one name: back to status only --
Java's message there is Spring Data's, and has not been measured.
- The citation is asked for by a versioned id, neither its stId nor its
dbId, so citing either instead of the id as given fails.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The new tests added uses of an untyped `base` and of untyped globals, raising the spec's implicit any (28 -> 34); typing them takes the module down instead, and the services' total 812 -> 794. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… value logged Three- and two-part occurrences fail at the same index whatever the read order; one part fails at 2 in Java's ([0],[2],[3],[1]) and at 1 in a naive one, so the spec now holds the order (shown failing under [0,1,2,3]). The log line names the raw occurrence again, to find the document by. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
After #575 the loose check held service.ts to its locked-in count, and this branch's outOfBounds calls had raised it (1529 -> 1539): javaSplit returned an untyped value. Typed, with fourParts (the first four parts, or Java's index failure in the order given) at the four sites, the count falls instead: loose 2769 -> 2709, implicit any 794 -> 789, both locked in. Answers on beta unchanged (flag and Solr capture sets identical). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.
Spec 006 (
specs/006-content-service-to-node). From the review of everything merged since #485. The two reviewers of the content service's unit tests found tests that would pass on wrong code; this PR fixes them. Each change was shown failing under the mutation it exists to catch.Tests
domain-snapshot.json) and the dbId asked for, so a load in the wrong direction, or of another object, fails./query/{id}/stIdand/normalPathwayare held to naming the attribute as the request spelled it./query/idsand/ids/map: tests where objects are found./idsis written in the HashSet order and/ids/mapin the HashMap order; both were recomputed with JDK 11 by the reviewer.hasDiagram), the species lookup by exact name, the release (releaseNumber) and discover's load.targetResultsmust be in Java's order, and the no-report check waits on a later report instead of 50 ms.One answer corrected. The review of this PR found four places answering the NullPointerException text where Java throws an
ArrayIndexOutOfBoundsException, which Java's GlobalExceptionHandler answers with its own message, as node already does for the measuredIndex 0 out of bounds for length 0:/diagram/{d}/occurrences,/diagram/{d}/flagand/fireworks/flag;Each now names the index Java reads first past the end, in the order search-core's bytecode reads them. Each has a test, and all four fail on the code before.
/fireworks/flagwith two Species of one name stays status-only: Java's message there is Spring Data's and has not been measured.Checks
🤖 Generated with Claude Code