fix(core): stop silently shortening gRPC deadlines on the wire

[cgreeno]

Two defects in grpc_core that make the deadline a caller asks for differ from the one that travels. Both are silent.

1. encode_timeout/1 truncates any duration ≥ 1000 ms to whole seconds

@ms_ceiling was 1000, so only sub-second values used the millisecond unit and everything above went through div(timeout, 1000):

caller asks	wire carries	peer reads	lost
1500 ms	"1S"	1000 ms	33%
2500 ms	"2S"	2000 ms	20%
3847 ms	"3S"	3000 ms	847 ms
5000 ms	"5S"	5000 ms	0

The wire format defines TimeoutValue as "a positive integer as ASCII string of at most 8 digits", with Millisecond among the valid units, so any duration below 100_000_000 ms is representable exactly and needs no coarser unit. This raises the ceiling to that limit and rescales the second/minute/hour ladder to stay inside 8 digits.

For comparison, grpc-go's EncodeDuration does the opposite of the current behaviour on both axes: it starts at nanoseconds and steps coarser only when the value will not fit, maximising precision, and its div() rounds up so a deadline is never silently shortened. Its maxTimeoutValue is 100000000 - 1 — the same 8-digit limit used here.

Round-number timeouts encode exactly (1000 -> "1S" -> 1000 ms), which is why this has gone unnoticed: a configured constant is usually a round number. A propagated deadline is not — it is whatever is left of the caller's budget — so the loss lands on every value and compounds at every hop.

2. TimeUtils.to_relative/2 returns a float, so :deadline is inert

The result was built as:

DateTime.to_unix(datetime, :second) * 1000 + elem(datetime.microsecond, 0) * 0.001

The trailing term makes every return value a float, and adds binary rounding error on top — 5.005 ms comes back as 5.0048828125.

append_timeout/2 matches on is_integer/1 and falls through to a catch-all, so passing deadline: to GRPC.Stub sends no grpc-timeout header at all. The gun adapter's start_timeout/1 has the same is_integer/:infinity clause pair with no catch-all, so a float also fails locally — as a FunctionClauseError that await/2 converts into a misleading terminated-stream error, and only when the response had not already arrived. Fast calls silently lose the deadline; slow ones fail pointing at the wrong cause.

DateTime.diff/3 over microseconds, truncated with div/2, replaces the hand-rolled arithmetic.

Relationship to #571

#571 independently ran into (2) and works around it at the call site in mint.ex:

milliseconds when is_number(milliseconds) -> max(0, round(milliseconds))

With this change that round/1 becomes redundant. The max(0, _) should stay — a deadline already in the past still resolves to a negative number of milliseconds (I measured -5003 for a deadline 5 s ago), and a receive timeout needs a non-negative integer.

Nothing here overlaps #571's own subject — that the mint adapter never applied the timeout at all — and this touches none of the files it touches. #571 also fixes :deadline being unable to override the :timeout that recv/2 fills in by default; that is left to it rather than duplicated here. Happy to rebase in whichever order suits you.

Verification

The existing encode_timeout tests asserted encoded strings and never a round-trip, which is precisely how the truncation survived — encode_timeout(1000) == "1S" holds both before and after data is lost. Added round-trip fidelity assertions, an 8-digit wire-limit check, and grpc-timeout header coverage. Every new assertion was confirmed to fail against the unfixed code.

Separately property-checked 448 values from 1 ms to 1.8×10¹³ ms: no encoding exceeds 8 digits, no decoded value is greater than its input, and the loss is always below the granularity of the unit chosen.

utils_test.exs moves from grpc/test to grpc_core/test. It covers a grpc_core module, but the grpc package resolves grpc_core from hex, so a test living there cannot exercise a local change to it — and its assertions, written against a 1000 ms ceiling, would have broken the next time grpc bumped grpc_core. http2_test.exs stays in grpc because it needs GRPC.Channel and GRPC.Server.Stream from sibling packages; the new header coverage lives in grpc_core against a bare map.

All three suites pass with --warnings-as-errors: grpc_core 116, grpc_server 211, grpc 342.

One open question

to_relative/2 here truncates down, on the reasoning that a conversion should never extend a deadline. grpc-go rounds up for the mirror reason — never shorten below what was asked. It is a ±1 ms difference; happy to flip it to match grpc-go if you would rather be consistent with the reference implementation.

[sleipnir]

Hi @cgreeno I merged the aforementioned PR, and if you want to continue from here, I'll be waiting.

[cgreeno]

Rebased onto master now that #571 has landed. Adds one commit required by that change.

The problem

#571 asserts is_float(timeout) on the value GRPC.TimeUtils.to_relative/2 returns. This PR changes that value to an integer, so the assertion fails.

CI for this PR does not show the failure. The grpc package resolves grpc_core from hex, so its suite runs against the published 1.0.4. Pointing grpc at local grpc_core source produces:

1) test receive_data/2 deadline accepts the float milliseconds a :deadline is resolved into
   code: assert is_float(timeout)

Without this commit, the test fails the next time grpc's grpc_core requirement is raised.

Type assertion

is_integer is also wrong: it fails against grpc_core 1.0.4, which returns a float. No concrete type assertion is correct for both versions.

The assertion is now is_number/1, matching the guard at the call site:

milliseconds when is_number(milliseconds) -> max(0, round(milliseconds))

is_number/1 accepts both float and integer, so it holds for either grpc_core version. The rest of the test is unchanged and still passes: a :deadline resolved through to_relative/2 is accepted and fires DEADLINE_EXCEEDED.

Call site

round/1 becomes redundant once to_relative/2 returns an integer. max(0, _) is still required: a deadline in the past resolves to a negative number of milliseconds, measured -5003 for one 5s ago, and a receive timeout must not be negative.

I did not change the implementation. The test records which of the two is required. round/1 can be removed in a separate PR.

Verification

Three suites, green against hex grpc_core 1.0.4 and against the patched source: grpc_core 116, grpc_server 211, grpc 350.

[cgreeno]

@sleipnir cleaned up comments my bad

[sleipnir]

Thank you @cgreeno