Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Import resume test fails when the wall clock steps back

Open Beginner friendly
  • Is something wrong?
#486 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
82/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
go, postgresql
Domain
databases, testing

Research direction

Read internal/definitions/apply_resume_test.go, especially stateOf and TestApplyRunAgainFinishesAnImportAStopCutShort; the issue identifies the comparison and the export ordering behind the failure. Sort exported types by key before comparing the resumed and clean import states. Run that test, including the three other import scenarios that add a type; done when clock ordering no longer causes false failures and the existing state comparisons still cover the listed fields, groups, values, and revisions.

Written by the indexing model from the issue text.

Description

bug help wanted

The test that stops an import and runs it again should fail only when the import leaves a different site, never because of the machine clock.

Current state: TestApplyRunAgainFinishesAnImportAStopCutShort compares the definitions export after a resumed import with the export after one clean run, using reflect.DeepEqual (internal/definitions/apply_resume_test.go:213). The export lists types in the order ListContentTypes returns them, ORDER BY t.created_at, t.key (internal/postgres/queries/types.sql:6-10). Both stamps come from the Go wall clock. Test setup stamps the recipe type in content.NewType (internal/content/types.go), and the import stamps the new wine type later in oneType (internal/definitions/apply.go:164). When the wall clock steps back between those two moments, wine gets the earlier stamp and the export lists post, wine, recipe instead of post, recipe, wine. Groups, values and revisions are still equal, but the comparison fails.

This was seen on a machine whose clock steps back about a second at a time. The databases pgtestdb kept from four failed subtests all held wine stamped about one second before recipe. Main failed 2 of 8 runs of this test alone there. Three other scenarios also add a type during the import and can fail the same way.

Proposal: in stateOf (internal/definitions/apply_resume_test.go:68-74), sort the exported types by key before the comparison. The import never sets the order of types, so the test still proves everything it proved before, every type field, every group in position order, every field, the item values and the revisions. The product keeps its type list order.

Trigger: found while reviewing #474, which does not touch this path.

Dominant language
Go
Stars
293
Forks
50
Avg merge
15h 38m
Merged PRs (30d)
126

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from gopherium/gophenberg

All issues in gopherium/gophenberg

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.