Repository navigation
[pull] main from DeusData:main - #129
Merged
Merged
Conversation
Signed-off-by: Pcristin <xxxokzxxx@protonmail.com>
…uration
strtoll answers 0 for text it cannot read, and cbm_parse_duration handed that
0 straight into its subtraction. The report of this said the result was a
false duration of zero. It is worse than that. An unreadable START time reads
as 0, so the span reports the whole END time as its duration:
FAIL tests/test_traces.c:340: info.duration_ns == 1050000000,
expected CBM_DURATION_UNKNOWN == -1
That is 1.05 seconds of measured time for a span whose start was never read.
Nothing downstream can tell that number from a real one.
The fix keeps cbm_parse_duration exactly as it is. It is public, it is
declared in traces.h, and eight tests pin its answers -- 0 for a NULL
argument, 0 for an end at or before the start. None of that moves.
A companion carries the extra answer instead:
int64_t cbm_parse_duration_checked(const char *start, const char *end, bool *ok);
Both reads go through one small reader that follows src/main.c:1104 -- an end
pointer, errno, and a check that nothing was left over -- plus a refusal of a
leading blank, which strtoll would otherwise step over.
cbm_extract_http_info now uses the companion and writes CBM_DURATION_UNKNOWN
(-1) when the timestamps do not read. It still returns true, because the
method and path on that span are still good data and dropping them would
punish them for a fault they had no part in. -1 as "not recorded" is the
sentinel this codebase already uses for the same question, in
CBM_EDGE_CONF_ABSENT. The duration_ns field comment in traces.h now says so,
so a reader who meets -1 has something to read.
Scope note: cbm_extract_http_info has no production caller on this tree. rg
finds it only in src/traces/traces.c, src/traces/traces.h and tests, and
handle_ingest_traces in src/mcp/mcp.c never touches a timestamp. So this is a
defect in a public, tested function rather than one putting bad rows in a
graph today.
Two tests come with the change. The one that pins the behaviour was seen
failing first -- the FAIL line above is from that run. After the fix,
TEST_SUITES="traces" reports 32 passed, 0 failed, exit 0.
The full suite reports 7633 passed, 2 failed. Both failures are in
tests/test_cli.c (lines 1749 and 6725), print "error: one or more agent
cleanup operations failed", and reproduce on a clean tree without this
change. make -f Makefile.cbm lint-ci passes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Joshua Richter <jrichter5781@gmail.com>
A dotted callee whose first segment starts upper-case names a type. That
receiver chain is evidence, and the two name-only strategies threw it away:
they matched on the final segment alone, so Foundation's
URLSession.shared.data bound to a project's own PickedFile.data — at 0.75
confidence, with nothing in the graph to show the answer was wrong.
receiver_chain_admits() now requires the candidate's own parent segment to
appear somewhere in that chain. Calendar.utcGregorian.startOfDayUTC still
resolves to AuthDTOs.Calendar.startOfDayUTC, because the project really does
extend Calendar and Calendar is in the chain.
Three shapes pass through untouched:
- a callee with no separator, which has no chain to judge;
- a lower-case root, which names a value whose declared type the chain does
not show (vm.load, http.Get, os.path.join);
- a name in capitals with underscores, which is a constant holding a value
rather than a type. Measured: without this carve-out the gate refused
ISO_4217_URL.lower -> builtins.str.lower, which is correct. JSON and URL
carry no underscore and stay guarded.
The gate applies only at the two name-only exits of resolve_name_lookup.
import_map, same_module and qualified_suffix already carry real evidence and
are left alone.
Language agnostic by design: the registry holds no language, and every
language that writes receiver chains gains the same protection.
Fixes #1893
Signed-off-by: Joshua Richter <jrichter5781@gmail.com>
…heir @page Follow-up to #1824, which mapped Blazor `.razor` to the C# host and extracted `@page` routes from it. `.cshtml` is the same Razor syntax with the same C# host and was equally unmapped: an ASP.NET Core MVC or Razor Pages application produced no nodes at all for its entire view tree. `@page` matters more here than it does for components. On a Blazor component the directive is an optional annotation; in Razor Pages it is the directive that *defines* a page, so the routable surface of a Razor Pages app lives exclusively in this file type. That is why the extension mapping alone is not enough. `cbm_path_is_razor()` hardcoded a single `.razor` suffix, so a `.cshtml` file would have been discovered and parsed but skipped by the directive scan -- present in the graph, with none of its routes. Widened to a suffix table covering both. Scope is deliberately the Razor family and nothing else: - `.vbhtml` is excluded because there is no VB.NET language in this repo, so there is no host to map it to. - `.aspx` / `.ascx` are excluded because Web Forms is a different templating syntax (`<%@ %>`, `runat="server"`) with no `@page` directive, so neither the C# error recovery nor the directive scan applies. Best-effort on the same terms as `.razor`: the C# grammar recovers the `@{ }` and `@functions` blocks, and the surrounding markup lands in ERROR regions reported through parse_partial. Tests: the extension mapping; a Razor Page asserting the extracted route path and method; and a negative case for a layout with no `@page`, since most `.cshtml` files are layouts and partials and a spurious Route node per view would be worse than the missing ones this fixes. Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
…able-timestamps fix(traces): stop an unreadable span timestamp from becoming a real duration
…in-mismatch fix(registry): refuse a name-only match the receiver chain contradicts
feat(extract): discover Razor Pages / MVC views (.cshtml) and route their @page
fix(pipeline): preserve dotted TypeScript import basenames
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )