Evaluate authored chunk counts separately from client-reported size. Only a complete trace ending at EOF within the 4096-byte application limit can become a completed mock result.
Set the limit independently of file metadata
Microsoft advises choosing an explicit maximum for the use case rather than using IBrowserFile.Size as the allowed size. That property is client-supplied metadata. Blazor file-upload guide.
This original example chooses an application limit of 4096 bytes. That is a teaching fixture's policy, not a Blazor default or a recommendation for every application.
The OpenReadStream API exposes maxAllowedSize and a cancellation token. The inspected signature defaults the maximum to 512000 bytes and documents rejection when declared Size exceeds the supplied maximum. Set the maximum explicitly and confirm the installed framework and render mode before implementation. OpenReadStream reference.
The C# reader should call OpenReadStream with maxAllowedSize: 4096 and the current operation's cancellation token. It must not derive that maximum from file.Size. The documentation's 10.0 selector and visible preview information are not evidence of which framework runs in your project.
Count returned bytes, then observe EOF
Design the application-level mock reader around this acceptance condition: total counted bytes do not exceed 4096, EOF has been observed, and the active operation has neither failed nor been canceled or superseded.
Use this original chunk sequence:
| Mock read | Bytes returned | Cumulative count | Status |
|---|---|---|---|
| 1 | 1024 | 1024 | Reading |
| 2 | 1024 | 2048 | Reading |
| 3 | 1024 | 3072 | Reading |
| 4 | 1024 | 4096 | Reading; EOF not yet established |
| 5 | 0, representing EOF | 4096 | Eligible for Completed |
The fourth read is the boundary test. Keep reading status until the next read establishes EOF. Do not stop at the limit and label a truncated prefix complete.
In a separate mock case, replace that EOF read with one returned byte. The count becomes 4097, so reject the operation as over limit and do not mark it Completed. Preserve the observed over-limit count in the test ledger; the prefix is not an accepted complete result.
Count bytes actually returned, not the allocated buffer's capacity. The 1024-byte chunks are supplied mock behavior, not a promise about how real asynchronous reads will be partitioned.
Test metadata disagreement without inventing framework behavior
A third original mock reports Size=100 while supplying the 4097-byte sequence. The application byte counter should reject it. This tests the independently authored reader contract.
It does not prove that a native IBrowserFile with dishonest metadata will deliver those exact bytes through OpenReadStream. The framework may reject an input before your counter receives the sequence. Keep native stream behavior in its own actual test record instead of presenting the mock as a measured framework result.
Similarly, an input whose declared Size is already above 4096 can be rejected by the documented native opening check before any successful reads. Do not claim your application observed 4097 bytes if opening failed first. Record the stage and actual exception when that case is later executed.
Preserve cancellation and selection identity
In a fourth mock case, cancel during reading. Its terminal state is Canceled, not Completed, even if some bytes were counted. Check the current cancellation and operation identity before publishing a success after EOF.
Reset or a new file selection should retire the previous operation's active outcome. Late reads or completion callbacks from the old selection must not overwrite the new selection's state. That behavior requires a native test; displaying a blank counter does not prove it.
Keep Idle, Reading, Completed, Rejected, Failed, and Canceled as meaningful states in the design. Record operation ID, limit, reported Size, read index, returned-byte count, cumulative count, EOF observation, cancellation, and terminal reason. An exception should remain a failure unless it is the intended cancellation outcome; a generic cleanup path must not turn either into success.
Keep reader tests separate from storage and transfer
The native deliverable is a C# reader and Blazor integration specification with mock EOF/count/cancellation cases and expected-versus-actual results. Record framework version, render mode, and cancellation behavior before testing integration.
Try the worked example
Evaluate four 1024-byte chunks without 0 to see Reading despite 4096 bytes. Add 0 for Completed. Replace 0 with 1 for Rejected 4097. The client-reported size 100 does not change the policy limit. Cancel a trace to keep it out of Completed. Observe EOF before declaring the whole stream complete.
The evaluator executes an authored byte-count contract, not a C# stream, Blazor integration, upload, or storage operation.
Recreate this example
Build one complete self-contained HTML page for this task: evaluate a bounded read trace and preserve EOF and cancellation semantics.
Use these exact original practice data and worked expectations: The application limit is 4096 bytes. Counts 1024,1024,1024,1024,0 total 4096 bytes and reach EOF: Completed. Replacing the final 0 with 1 totals 4097 bytes: Rejected. A reported Size of 100 cannot raise the limit. Cancellation remains Canceled.
Implement the following useful local interactions: Comma-separated chunk counts and reported-size input. Evaluate counts actual returned chunks; 0 means EOF; no EOF remains Reading; extra chunks after EOF invalid. Reject overlimit; cancellation distinct. Reset restores default. Explicit mock trace, not native Blazor execution. Preserve the supplied source text and distinguish an uncomputed state, a successful local result, and an invalid or incomplete input. Update output only from the current input snapshot. An input edit must retire stale feedback until the reader runs the relevant action again. Do not silently invent missing values or replace a failing case with a success.
Design the page as a compact source-and-result developer workbench with readable code, labeled inputs, and a separate explanation area. Put a compact task heading, actual sample data, the main result, and usable controls early enough to be useful on a narrow screen. Use readable text of at least 16px, generous paragraph spacing, strong contrast, native labels, accessible buttons, and visible keyboard focus. Stack long records at 360px and wrap code without page-level horizontal overflow.
Use type=button and explicit querySelector-based click handlers rather than relying on form submission. If Enter is useful, handle it only on the relevant input and ignore isComposing. Keep effects within this open page; no remote dependencies, network calls, persistence, fake downloads, or automated sending. The evaluator executes an authored byte-count contract, not a C# stream, Blazor integration, upload, or storage operation. Place worked explanations beside their data and identify teacher or synthetic examples clearly. Output only the complete HTML document, with inline styles and script and LF line endings.
Review the bounded stream-trace evaluator in NOS
Use these boundary cases in a native reader test with your installed framework and render mode. Review the trace explanation in NOS to distinguish 4096 bytes still Reading from 4096 bytes followed by EOF, then revise eligible static EOF instructions in visual editing mode if completion is unclear.