Conversation
The pacing settings shipped in 0.5.0 were only ever exercised against fakes. Nothing measured whether upload traffic actually delays the app's own requests, or by how much, so the tuning advice rested on the mechanism being plausible rather than on a number. Adds a `netbench` scenario to the existing e2e harness rather than a separate project: the mock intake already serves both the SDK's uploads and a stand-in origin for the app's requests, which is exactly the shared link the experiment needs. Runs are driven by `aa start --ps` and collected from HiLog, so a whole run is scriptable over hdc with no tapping, on an emulator or a real device. The link model matters and the obvious one is wrong. A token bucket sized to a second of bytes measures nothing: it starts full, so a request smaller than the bucket draws its bytes instantly and never queues. Real links have no burst credit — they serialize at the line rate, and a request arriving mid-transmission waits. That queueing is the effect under test, so the server models a link, not a quota. Throttling stays opt-in via UPLINK_BPS, leaving existing smoke runs untouched. Arms alternate round by round rather than running as two blocks, so drift over the session cancels instead of landing entirely on whichever arm ran second. Known limitation, recorded here because the numbers look usable and are not: the harness force-flushes to guarantee the upload overlaps the measured request, and a force-flush bypasses the very pacing it is meant to compare. Results are therefore valid for "does upload traffic cause contention" (it does — p95 rose 32-44% at 2.7 Mbps) and invalid for comparing BatchProcessingLevel settings. A second iteration needs organic load and no flush.
The first harness alternated uploads on/off round by round inside a single run and force-flushed each round to guarantee the upload overlapped the measured request. Both choices defeated the experiment. The flush was the direct problem: forcing an upload bypasses the batch window, the cycle interval and the per-cycle bound, so every setting the run existed to compare was inert. Load is now organic — events are generated continuously and the SDK's own scheduler decides when to upload. The alternation was the subtler one. Consent PENDING stops new drains, not an upload already in flight, so once an upload outlives its round it spills into the supposedly quiet arm and both arms carry upload traffic. At 0.5 Mbps that erased the effect completely: p95 delta fell from +32..44% to roughly zero, not because contention had gone but because the baseline had become contaminated. Groups are now whole runs, with drift handled by repetition and medians. With that, the settings separate cleanly and reproducibly. At 2.7 Mbps against a silent-SDK baseline, the default pacing costs +59% at p95 while RARE + LARGE + LOW costs +7%; at 0.5 Mbps, +53% against +20%. Same direction at both, which is what the shipped tuning advice claims.
The launch-parameter plumbing defaulted every knob, and so did the code that reads them, which left two copies to drift apart. They had: the forwarder supplied 200 events and 'demo' pacing, the reader assumed 10 and 'off'. Since the forwarder always wrote, its copy always won and the reader's was dead — so omitting a parameter quietly ran a different experiment than the one the reader described. Under the between-group semantics 200 meant 200 events every 20 ms. Forward a parameter only when it was actually supplied, and keep the defaults where they are read. A measurement tool that silently changes what it measures is worse than one that fails.
Add a network-contention benchmark to the demo harness
The uploadFlashcatSymbols task declared dependencies on both assembleHap and assembleHar. A module has at most one of them, so hvigor failed task-graph resolution with "Cannot find hvigor task 'assembleHar' in module 'entry'" and the build stopped. The task now declares no build dependencies: run it after a release build as its own hvigor invocation. The build directory now follows the product being built, read from the project's OHOS app context, so -p product=beta scans build/beta. It previously defaulted to build/default and silently scanned the wrong directory for every other product, which could upload a stale build's sourcemap under the new version. buildDir remains available as an override. The resolved directory is now logged, and the "no sourceMaps.map found" message names the path it searched, so a wrong directory is visible in the build output instead of reading as missing sourcemap output. Wire the plugin into the demo entry module and run its task from the build gate. Hosted Linux CI cannot run hvigor, so nothing exercised the plugin against a real task graph, and plugin.ts had no tests at all. Document that the upload task needs --no-daemon when it is configured from environment variables: hvigor's daemon copies the environment once when it is created and afterwards refreshes only a fixed allowlist, so a reused daemon hands the plugin stale or empty values, silently.
The uploadFlashcatSymbols task declares no build dependencies, so it runs only when it is named on the command line. Naming it is already the switch: a second gate could only ever skip an upload that was explicitly asked for, and it did so without a log line, which is indistinguishable from a successful no-op run. Every remaining skip path states its reason, so an upload that does nothing now always says why.
npm install can update package-lock.json as a side effect, which is the wrong behaviour for a gate that is supposed to check the committed state. The hosted plugin test job already uses npm ci.
hvigor-plugin 0.1.4: fix task registration and build-dir resolution
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Brings
publishup to date withmainsohvigor-plugin-v0.1.4can be tagged.0.1.4 fixes the upload task: it declared dependencies on both
assembleHapandassembleHar, and a module has at most one of those, so task-graph resolution failed and the build stopped. It also follows the product being built when locating build artifacts, instead of always scanningbuild/default, and drops the redundantenabledoption.See #34 for the full change.