< Summary - AsyncResponse (Release / net8.0+net10.0 / unit+integration)

Information
Class: AsyncResponse.WorkerJobTooLargeException
Assembly: AsyncResponse.Abstractions
File(s): /_/src/AsyncResponse.Abstractions/WorkerJobTooLargeException.cs
Line coverage
100%
Covered lines: 9
Uncovered lines: 0
Coverable lines: 9
Total lines: 43
Line coverage: 100%
Branch coverage
N/A
Covered branches: 0
Total branches: 0
Branch coverage: N/A
Method coverage

Feature is only available for sponsors

Upgrade to PRO version

Metrics

MethodBranch coverage Crap Score Cyclomatic complexity Line coverage
.ctor(...)100%11100%
get_SerializedLength()100%11100%
get_Limit()100%11100%

File(s)

/_/src/AsyncResponse.Abstractions/WorkerJobTooLargeException.cs

#LineLine coverage
 1namespace AsyncResponse;
 2
 3/// <summary>
 4/// Thrown by every <c>EnqueueWorkerAsync</c> overload — and by <c>IDurableFlows.StartAsync</c>,
 5/// whose start job carries the initial ledger — when the serialized worker envelope exceeds
 6/// <c>AsyncResponseOptions.MaxInboundMessageChars</c>, the budget the consuming ingress enforces.
 7/// Nothing was published.
 8/// <para>
 9/// Without this producer-side check the job left the process: the transport accepted it (every
 10/// database transport and most brokers take far more than the engine's default 8 Mi
 11/// characters), the ingress then acknowledged it <em>without executing it</em> — an oversized
 12/// message never gets smaller, so redelivering it would hot-loop — and the caller held a flow id
 13/// for a run recorded as <c>Running</c> that nothing would ever execute. Failing here, in the
 14/// caller's stack, is the only place the mistake can still be corrected.
 15/// </para>
 16/// <para>
 17/// The measurement is exact: the envelope is serialized the way the transports serialize it and
 18/// compared in UTF-16 code units, which is what the ingress compares. JSON escaping counts — a
 19/// 5 Mi-character argument of quotes or non-ASCII text serializes to several times its length.
 20/// The producer's own <c>MaxInboundMessageChars</c> stands in for the consumer's; keep the option
 21/// identical across the processes of one deployment. Put large arguments behind a claim check
 22/// (persist the data and pass a reference) rather than raising the limit.
 23/// </para>
 24/// </summary>
 25public sealed class WorkerJobTooLargeException : InvalidOperationException
 26{
 27    /// <summary>Creates the exception for an envelope of <paramref name="serializedLength"/> code units over <paramref 
 28    public WorkerJobTooLargeException(int serializedLength, int limit)
 1029        : base(
 1030            $"The worker job envelope serializes to {serializedLength} UTF-16 code units, over the {limit} the consuming
 1031            "accepts (AsyncResponseOptions.MaxInboundMessageChars); it would be acknowledged without ever executing. Not
 1032            "published. Put large arguments behind a claim check (persist the data and pass a reference) rather than rai
 33    {
 1034        SerializedLength = serializedLength;
 1035        Limit = limit;
 1036    }
 37
 38    /// <summary>The envelope's serialized length in UTF-16 code units, as the ingress would measure it.</summary>
 839    public int SerializedLength { get; }
 40
 41    /// <summary>The configured budget the envelope exceeded.</summary>
 642    public int Limit { get; }
 43}