Loading workspace insights... Statistics interval
7 days30 daysLatest CI Pipeline Executions
19cecda6 🐛 Fixed members import failing on a file with no rows
An empty upload — a file with no bytes, or headers with no rows — used to
fail with a 500, "Cannot convert undefined or null to object": the importer
derived its column list from the first parsed row and there was none.
Nothing guarded this on the server. The upload middleware checks only that a
file was attached and that its type is allowed, and the admin import modal
catches the empty case in the browser, so it was reachable by anything
driving the API directly.
The importer now chooses its path explicitly rather than by accident.
Nothing to import returns immediately, reporting that nothing was imported.
An import small enough to finish while the request is open is performed
there. Everything else is handed to a background job. An empty upload
short-circuits in prepare() before any file is written or import is
performed, so process() returns on the zero row count before it would reach
for a file that does not exist — the branch is load-bearing rather than a
fall-through that happened to produce the right result.
The middle path reads as a question about cost rather than size: an import
carrying populated Stripe data is deferred whatever its row count, because
resolving Stripe data per row is slow.
The count of rows to import was previously called batches, a name inherited
from a batch size that had been fixed at 1, so it had equalled the row count
for as long as the constant existed; it is now rowCount.
Tests drive all three paths through the API, with the inline threshold set
per test so the same small fixture stands on either side of it rather than
needing a fixture large enough to cross the shipped default.