Summary

  • LACNIC’s new regression test forces uploads onto a temporary-file path and proves that Wicket’s FileUpload.getBytes() returns exactly the bytes that were written.
  • The files called organizations.xlsx and carta-ce.pdf are synthetic byte strings, not a real OOXML workbook and a complete PDF; format, business-rule, access and resource-limit evidence lives at other layers.
  • The right response is not to discard the fast compatibility test, but to label its claim precisely and pair it with real-document, parser, workflow and bounded-execution receipts.

A filename can overstate a test

The most consequential line in a software test is sometimes not the assertion. It is the name. On 11 September 2026, LACNIC added wicketFileUploadGetBytesWorksForDiskBackedExcelAndPdf to the public repository for its election system. The method sounds like a compact acceptance statement for two document formats. It is narrower and, understood correctly, useful.

The test creates a Commons FileUpload DiskFileItemFactory, points it at a JUnit temporary directory and sets the buffer size to one byte. Any non-empty fixture crosses the threshold and is stored on disk. The helper writes a byte array, wraps the item in Wicket’s FileUpload, calls getBytes(), compares the returned array with the original and deletes the temporary item in a finally block. That is an intentionally sharp compatibility probe. It asks whether the application’s chosen multipart object and Wicket adapter agree when storage falls back from memory to a file.

The two assertions deserve literal reading. The value named spreadsheet is UTF-8 text: a heading, ORGID, followed by ALFA-001. The value named pdf is the ASCII sequence %PDF-1.1, a newline, %carta, and another newline. The helper assigns the filenames organizations.xlsx and carta-ce.pdf. It never opens the first value with an OOXML reader. It never parses the second value as a PDF. The assertions establish byte identity, independent of what those bytes mean.

That distinction is more than testing pedantry. A filename is supplied by a caller. A content type is also a claim made at the edge. A document format is a structure: an .xlsx workbook is an OOXML package with parts and relationships; a PDF has objects, cross-references and an end structure beyond its leading magic bytes. The test’s fixtures are legitimate if the claim is “disk-backed bytes survive the adapter”. They become misleading only when their names are allowed to stand in for “Excel and PDF were accepted correctly”.

What the repository proves elsewhere

The commit should not be read as evidence that LACNIC has no document controls. The same test class makes the contrast unusually clear. One neighbouring test passes text disguised as photo.jpg through the candidate-picture validator and expects an invalid-format result. Another creates a real PNG, processes it through the same validator, expects a JPEG output and checks that the decoded dimensions are no greater than 400 by 400 pixels. Those tests cross from transport into content semantics. The image must decode, transform and remain within a stated result boundary.

The organisation workbook path also goes further than the new compatibility method. Its UI validator initially accepts an upload if either the client filename ends in .xlsx or the claimed MIME type is the OOXML spreadsheet value. That edge check is permissive, but it is not the end of the path. Debtor and delete workflows send the bytes to remote validation; upsert performs detailed validation when the form is submitted. The shared ExcelUtils code writes the bytes to a temporary file, requires the OOXML MIME value, constructs an Apache POI XSSFWorkbook, selects the first sheet and checks expected headings and rows. The organisation workflows then perform operation-specific checks before asking an asynchronous worker to apply a change.

That downstream work matters. A plain-text ORGID fixture with an .xlsx name can pass the new adapter test and still fail the real workbook parser. This is not a contradiction. It shows why one receipt cannot answer every question. The adapter test protects a library boundary; the parser protects document structure; the organisation validators protect required columns, identifiers and operation-specific conditions; the submission path decides whether work may be queued.

The census flow has the same broad separation. The upload component obtains Wicket’s FileUpload, invokes election-specific validation on the bytes and only then tries to queue a census update. Again, the presence of getBytes() links the new regression test to a real call shape, but the test does not execute the census validator, the workbook parser or the queue decision.

The result-letter flow uses a different control set. Its form is multipart and capped at 10 MB. On submission it reloads the election, enforces access and refuses to proceed if the election is closed. It independently checks the optional Spanish, English and Portuguese letter uploads. If they pass, it stores the selected bytes through the election manager along with administrator and client-IP context.

Yet the format test for those letters is deliberately slight: ElectionResultLetterSupport.isPdf returns true when the first four bytes are %PDF. The synthetic %PDF-1.1\n%carta\n fixture satisfies that prefix. It does not demonstrate a complete, renderable or policy-compliant document. Here too the repository contains real workflow controls, while document-structure assurance remains a separate claim.

Five receipts, not one green tick

A defensible upload test suite can be read as a set of receipts. Each receipt should say what crossed a boundary, under which dependency versions, and what was deliberately left unproved.

The first is the transport receipt. It should force both in-memory and disk-backed storage, use exact byte comparisons, verify cleanup and, where relevant, test stream closure and repeated reads. LACNIC’s new method is a good seed for this layer. The test should be named for the invariant it actually checks: disk-backed FileUpload.getBytes() preserves byte identity for representative payloads. The filenames can stay, but the test name and comments should prevent them from borrowing the authority of a parser.

The second is the format receipt. It needs small, structurally valid fixtures created by the actual format tooling, plus malformed and deceptive counterexamples. For OOXML that means a genuine workbook package with the required sheet and headings, a ZIP that is not OOXML, a truncated package, and perhaps encrypted or password-protected cases according to product policy. For PDF it means at least one complete minimal document that a chosen parser accepts, plus a header-only value, a truncated file and a polyglot or trailing-content case if those risks are relevant.

Signature checks can be part of this layer, but they should not be its conclusion.

The third is the domain receipt. The workbook must not merely open. The expected headings must resolve, blank and duplicate organisation identifiers must fail in the intended way, invalid country or vote values must produce stable feedback, and an error report should describe the rows it rejected. The census fixture should exercise the actual required columns and election-specific checks. A parser exception and a business rejection are different outcomes and should remain distinguishable to operators.

The fourth is the workflow receipt. An authorised administrator should be able to submit an open election; an unauthorised session or closed election should not. A rejected file should not queue a change. A valid file should produce exactly the expected durable effect and audit context. Concurrent submissions should encounter the intended “already processing” behaviour. For result letters, tests should cover all three language slots, removal of an existing letter, retention when no replacement is supplied, and a failure in one upload before any of the three values is applied.

The fifth is the resource receipt. An input-size ceiling, memory behaviour, temporary-file location, cleanup, parser timeout and compressed expansion limit are separate from byte correctness. Apache Commons FileUpload documents threshold-based memory versus temporary-file storage and offers request-size controls. Apache POI’s security guidance warns that document parsers cannot neutralise every hostile effect; its ZipSecureFile exposes compression-ratio and uncompressed-entry limits. OWASP similarly recommends layered extension, content-type, signature, authorisation and size checks, including attention to size after decompression. None of that proves a flaw in LACNIC’s application. It describes the questions a complete acceptance record should answer.

The operational lesson is about claim discipline

Regression tests become institutional evidence. They are cited during upgrades, incidents and reviews, long after the author remembers their narrow purpose. A test called “works for disk-backed Excel and PDF” may later be offered as evidence that Excel and PDF uploads are covered. The code will still tell the truth, but the summary will have become broader than the experiment.

The remedy is inexpensive. Keep the quick test. Rename it around byte preservation. Add one assertion that the factory really produced a disk-backed item, so a future library change cannot silently move the test onto the in-memory path. Record the relevant Wicket and Commons FileUpload versions in the build receipt. Then link, rather than conflate, the transport test with real workbook, PDF, domain and workflow suites.

That last point matters because the pinned repository declares Wicket 10.9.0 and packages POI OOXML 5.0.0 in its WildFly module. These declarations describe the inspected source tree, not a verified production deployment. A dependency upgrade and a follow-up regression test close in time do not prove that the upgrade caused a defect. They do suggest why a compatibility receipt is sensible: multipart libraries, framework wrappers and storage thresholds meet at an edge that can fail without the document parser changing at all.

Good evidence keeps that causal boundary intact. “The same bytes came back” is strong when it is the answer to the right question. It is weak only when it is asked to certify a workbook it never opened, a PDF it never parsed, an election state it never checked or a resource envelope it never measured.

Sources