Update Test Schema: SSR Router Link Load
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 42/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- typescript
Research direction
Start by reviewing the shared schema introduced in PR #647, especially createBenchmarkBaseSchema, TestBaseSchema, and MetricBaseSchema, then locate the SSR Router Link Load schema and its result generation, validation, persistence, and consumers. Check which historical records contain the required identity, run, iteration, and metric data before migrating them; do not infer missing values. Done means the test uses the shared schema, affected consumers and records follow the chosen migration approach, and that approach is documented.
Written by the indexing model from the issue text.
Description
Update this test's schema to use the shared base or benchmark schema introduced in https://github.com/e18e/framework-tracker/pull/647.
Scope: router-link load sweeps, stages, throughput, latency, requests, and errors.
Use createBenchmarkBaseSchema with a concrete iteration schema, inheriting TestBaseSchema. Use MetricBaseSchema for each statistical measurement. Record runs and required iterations at the benchmark level.
Include the required test identity fields: name, framework, and packagePath. Update result generation, validation, persistence, and consumers as needed.
Where historical test data is available, convert past records to the new schema. Where the required data is unavailable, use the new schema going forward; do not invent missing measurements or iterations.
As a last resort, if the historical schema cannot reasonably be migrated, consider dropping affected past records or re-running the test using the dependency snapshots retained in the main test records/schema. Document the chosen approach.
Blocked by #647, the shared-schema part of #633.
Part of #633
- Dominant language
- TypeScript
- Stars
- 42
- Forks
- 16
- Avg merge
- 13h 41m
- Merged PRs (30d)
- 144
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from e18e/framework-tracker
-
documentation
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
e18e/framework-tracker#640 ·
Maintainers usually reply within 1 day
-
documentation
Difficulty 3/5 1-2 days Newbie friendliness 45/100
e18e/framework-tracker#666 ·
Maintainers usually reply within 1 day
-
Variance ChartsOpendocumentation
Difficulty 5/5 Over a week Newbie friendliness 35/100
e18e/framework-tracker#665 ·
Maintainers usually reply within 1 day
-
TanStack Bar ChartOpendocumentation
Difficulty 4/5 3-5 days Newbie friendliness 45/100
e18e/framework-tracker#664 ·
Maintainers usually reply within 1 day
-
TanStack Line ChartOpendocumentation
Difficulty 4/5 1-2 days Newbie friendliness 45/100
e18e/framework-tracker#663 ·
Maintainers usually reply within 1 day
All issues in e18e/framework-tracker
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 1-3 hours Newbie friendliness 72/100
zts212653/clowder-ai#1678 ·
Maintainers usually reply within 1 day
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
Progressive-Victory/the-website#680 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100