Skip to content

Clarify Gremlin.Net type limitations with reproductions - #3683

Open
spmallette wants to merge 2 commits into
apache:masterfrom
spmallette:tp-docs-gremlin-dotnet-limitations-171
Open

spmallette wants to merge 2 commits into
apache:masterfrom
spmallette:tp-docs-gremlin-dotnet-limitations-171

Conversation

@spmallette

Copy link
Copy Markdown
Contributor

Sharpen the Gremlin.Net Limitations section so each type-range limitation states its true trigger and can be reproduced. The DateTimeOffset entry now notes that the +/-14:00 offset bound is the common trigger, not just the year range. The null Map key entry explains that group()/groupCount() over a missing property drops the element rather than producing a null key, so a null key must be injected explicitly. The Duration and non-BMP char entries clarify that only out-of-range values are affected. A short csharp example reproduces the offset, high-precision decimal, and null-key cases against a modern-graph server.

@codecov-commenter

codecov-commenter commented Sep 25, 2026 •

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.05%. Comparing base (a28cd1f) to head (368c2b5).
⚠️ Report is 650 commits behind head on master.

Additional details and impacted files
@@             Coverage Diff              @@
##             master    #3683      +/-   ##
============================================
+ Coverage     76.35%   80.05%   +3.69%     
============================================
  Files          1012       32     -980     
  Lines         60341     6913   -53428     
  Branches       7075        0    -7075     
============================================
- Hits          46076     5534   -40542     
+ Misses        11548     1053   -10495     
+ Partials       2717      326    -2391     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Comment thread docs/src/reference/gremlin-variants.asciidoc Outdated
Comment thread docs/src/reference/gremlin-variants.asciidoc Outdated
Comment thread docs/src/reference/gremlin-variants.asciidoc Outdated
Sharpen the Gremlin.Net Limitations section so each type-range limitation states
its true trigger and the concrete behavior a user hits when the server returns an
out-of-range value.

The DateTimeOffset entry notes that the +/-14:00 offset bound, not merely an
extreme year, is the common trigger, and that the DateTimeOffset constructor
rejects the value so Gremlin.Net raises an ArgumentOutOfRangeException while
reading the result. The Duration and BigDecimal entries name the OverflowException
raised when a value exceeds the TimeSpan range or the decimal precision of 28-29
digits. The null Map key entry states that such a result raises an IOException.
The non-BMP character entry now states the real behavior: the four-byte Char is
decoded into a surrogate pair of which only the leading surrogate is returned, so
the character is silently corrupted without an error.

Assisted-by: Kiro:claude-opus-4.8
@spmallette
spmallette force-pushed the tp-docs-gremlin-dotnet-limitations-171 branch from 7cde46e to d0fbc28 Compare September 25, 2026 16:56
so offset date-time values at those boundaries will fail to deserialize.
* Gremlin's `Duration` type has a much larger range than C#'s `TimeSpan`, so extreme duration values (such as
`Duration.FOREVER`) that exceed `TimeSpan.MaxValue` or `TimeSpan.MinValue` will fail to deserialize.
* C#'s `DateTimeOffset` accepts offsets only in the range `-14:00` to `+14:00` and years from 1 to 9999, while

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both the DateTime and Duration entries here cover the range limitation accurately, but there is also a precision limitation when converting from gremlin types to dotnet. Gremlin uses nanosecond precision for both types, while dotnet is limited to 100ns "ticks". These types are truncated upon deserialization (00.123456789s -> 00.1234567s)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is one other weird case with DateTimeOffset in .Net, the offset is specified in whole minutes, while Java and GraphBinary specify the offset as a number of seconds. It appears that datetimes with a sub-minute precision offset currently throw an ArgumentException when attempting to deserialize in .Net. We should document this for now, it's probably worth a JIRA to intercept this and truncate the seconds portion of the offset.

@Cole-Greer

Copy link
Copy Markdown
Contributor

VOTE +1 pending comment resolution

The Gremlin.Net limitations section now notes two further deserialization
behaviors for temporal types. Both DateTimeOffset and Duration silently
truncate fractional seconds finer than the .NET 100-nanosecond tick, since
Gremlin represents time with nanosecond precision. A DateTimeOffset whose
UTC offset carries a sub-minute component also cannot be represented, because
.NET expresses the offset in whole minutes while Java and GraphBinary express
it in seconds, and Gremlin.Net raises an ArgumentException in that case.

Assisted-by: Kiro:claude-opus-4.8
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants