Pixellint 0.42.0 checks Mixpanel and Segment batch cardinality.
A valid record does not establish a valid batch.
An event validator can check the name, identifier, timestamp and property types of every record while overlooking the array that contains them. If the sender combines too many valid records into one request, those field checks remain true. The aggregate request still breaches a destination contract. Batch depth therefore needs a separate assertion about the complete container, alongside the existing assertions about each record.
Pixellint already recognizes these analytics vendors and inspects their supported event payloads. This release adds two documented cardinality constraints to those existing packs. It does not require a new vendor directory entry or infer a limit from the largest sample seen in a capture window. The relevant limits come from current destination documentation, and the independently authored controls exercise both sides of each boundary.
The change is deliberately specific. A count measures how many records are in the observed batch. It does not establish how large they are, whether a project token is active, whether a destination accepted the request, or whether downstream analytics reports contain the intended events. Those questions require their own evidence and, where supported, their own rules.
Mixpanel Track arrays allow at most 2,000 events.
The Mixpanel Track reference lists 2,000 events per request. The Track pack now applies that maximum to supported event arrays. An array with 2,000 records satisfies the count constraint. Adding a 2,001st record produces an aggregate error even when the added record has a populated event name and project token.
The event rules continue to run. A record with a missing name remains a record with a missing name inside an oversized batch. The count finding describes the container, while the existing field finding points to the affected record. This preserves useful repair information instead of replacing every event result with a single general rejection.
Track and Import remain separate endpoint owners. Import already had a documented maximum on its batch and has its own required event fields, transport checks and compressed capture support. Adding a maximum to Track does not copy Import authentication requirements into a client-side Track event or make the two ingestion operations interchangeable.
Segment batch arrays allow at most 2,500 calls.
The Segment HTTP API troubleshooting section specifies at most 2,500 events per batch. It also explains that an excessive event count can receive HTTP 200 while events are rejected. The Segment pack now checks the observed batch array against that maximum. The enclosing request object still carries the batch, authentication alternatives and any shared context.
The count applies to the array as a whole. Mixed method calls do not get separate allowances because their type fields differ. Existing record checks retain their own conditions: a Track call needs an event name, and other call types have their corresponding documented fields. A batch of different call types can satisfy every individual requirement and still exceed the aggregate maximum.
A single-event endpoint retains its individual request contract. This release does not turn an ordinary Track or Identify object into a batch by counting its properties, and it does not manufacture missing neighboring events. The validator evaluates the supported structure actually supplied by the caller.
Boundary controls isolate the count from event defects.
The decisive fixtures use synthetic records with the fields needed by their selected pack. A Mixpanel fixture at 2,000 records and another at 2,001 differ in their cardinality. Segment fixtures do the same at 2,500 and 2,501. Expected findings are authored from the published maximum, so the candidate engine cannot define its own expected result.
Neighboring controls cover empty arrays, the wrong container type and records with independent field defects. These cases establish that a maximum has not accidentally replaced an existing minimum or type check. They also show whether an oversized request keeps useful record-level findings. Endpoint selection controls ensure that another ingestion operation does not inherit a limit merely because the vendor name matches.
The release compares complete reports across the native engine and JavaScript bindings at explicit reference clocks. That comparison includes more than a final error count: owning pack, severity, field target, provenance and the ordinary report structure all matter. Browser controls use the shipped WASM bundle so the website demonstrates the same contract users receive from the package.
Synthetic detection gains stay separate from captured vendor use.
The private regression corpus supplies evidence that these destination packs occur in real submissions and that their established behavior remains stable. It is a finite set of historical artifacts. A documented batch limit can be a real coverage gap even when no stored submission happens to cross that boundary. An independently authored oversized batch supplies evidence about that limit without becoming a claim about a customer request.
The release measurements therefore report captured-corpus changes and synthetic boundary changes separately. The corpus is replayed with the original reference clocks, using the previous release as the baseline. The synthetic controls retain their own static expectations and before-and-after results. An unchanged corpus is a legitimate result when the relevant stored arrays are below the new maxima.
The full private D1 replay compared all 8,836 artifacts with 0.41.0 and 0.42.0 at their original capture clocks. Every report stayed unchanged: 324 errors, 769 warnings and 250 artifacts with an error in each version, with no engine exceptions. Separate source-authored controls tested the missing batch boundaries. All 38 candidate outcomes matched their static expectations, compared with 22 on the previous version. Sixteen controls gained one count error each, including 14 previously clean controls and two that retained their existing event errors. The complete authored reports matched across native, Node and browser WASM in 114 comparisons. Ordinary corpus parity covered all JSON and URL pastes plus selected VAST representatives, with 708 comparisons across 236 artifacts. These authored overflow results are separate from the unchanged observed corpus.
Cardinality and byte quotas require different evidence.
A small number of large records can exceed a byte quota while satisfying a record limit. A large number of small records can do the reverse. The two checks answer different questions. Whitespace, Unicode and transport encoding also affect which bytes are observable, so a count maximum cannot stand in for a separately documented request-size constraint.
This release adds the two count limits. Existing size, field and transport checks keep their own scope, and the depth audit records remaining requirements rather than claiming complete destination validation. Receiver quotas with unresolved units or conflicting documentation need separate review before the package can impose a precise error boundary.
A clean local report establishes only that the evaluated contracts found no violation in the available evidence. It cannot prove source-key validity, delivery, account permissions, rate-limit state or downstream ingestion. Pack pages show the checked contracts beside their references so integrations can decide what additional observation or live verification they need.
The release keeps its review evidence inspectable.
The local release checks passed 581 Rust tests, strict workspace clippy, formatting and npm smoke tests. Independent native and Node probes checked the corrected encoded arrays and preserved single-event objects. Actual desktop and mobile browser checks exercised the shared WASM engine, count errors, source links and request-local privacy. The source depth inventory retains current reviews for all 164 vendor packs. Publication verification compares the npm package, four Rust crates, MCP entry, four native CLI archives and the deployed Pixellint and Vastlint engines with the reviewed release. The aggregate replay evidence is linked below so corpus counts and authored improvements remain inspectable without exposing submitted payloads.
The Mixpanel Track and Segment pack pages identify the aggregate constraints together with their existing event checks. The public replay report contains aggregate measurements and scope limits. Customer artifacts remain in private local replay files. Examples and published controls use synthetic data so the release can demonstrate its behavior without exposing captured credentials or customer payloads.
Integrations can apply the new release to their existing supported JSON and capture inputs, then inspect an oversized batch at the container finding and any remaining invalid fields at their individual findings. Choosing a request size within the count limit is one step in preparing a valid destination request. The pack inventory and remaining-requirements audit make the rest of that work explicit.
Sources
Contract pages
The dated argument is above. These pages are the field lists.