Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

feat(coderd/database/dbtestutil): set default database timezone to non-UTC in unit tests#9672

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
johnstcn merged 17 commits intomainfromcj/dbtestutil-rand-tz
Sep 15, 2023

Conversation

johnstcn
Copy link
Member

@johnstcnjohnstcn commentedSep 13, 2023
edited
Loading

This PR:

  • Addsdbtestutil.WithTimezone(tz) to allow setting the timezone for a test database.
  • Modifies our test database setup code to pick a consistently weird timezone for the database.
  • Adds the facilityrandtz.Name() to pick a random timezone which is consistent across subtests (viasync.Once).
  • Adds a linter rule to warn against setting the test database timezone to UTC.

This has already surfaced a few timezone-related bugs that we can fix in follow-up PRs, but which are now obvious and trackable via their use ofdbtestutil.WithTimezone("UTC").

mtojek reacted with rocket emoji
@johnstcnjohnstcn self-assigned thisSep 13, 2023
t.Logf("setting timezone of database %q to %q",dbname,tz)
// We apparently can't use placeholders here, sadly.
// nolint: gosec // This is not user input and this is only executed in tests
_,err=sqlDB.Exec(fmt.Sprintf("ALTER DATABASE %s SET TIMEZONE TO %q",dbname,tz))
Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

self-review: I hate this but it appears necessary.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

It's fine in tests, IMO. It's an unfortunate limitation of some PostgreSQL queries.

@Emyrk
Copy link
Member

Some chaos could find a decent amount of TZ bugs

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

It looks like I had timezone-related bug in#9652 that this surfaced.

Comment on lines 32 to 40
// WithTimezone sets the database to the defined timezone instead of
// to a random one.
//
// Deprecated: If you need to use this, you may have a timezone-related bug.
funcWithTimezone(tzstring)Option {
returnfunc(o*options) {
o.fixedTimezone=tz
}
}
Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

review: I originally exposed this asWithFixedTimezone() but I quickly realized that it's useful to be able to set a specific timezone in unit tests, especially when you're trying to narrow down the root cause of a timezone-related bug.

mafredri and Emyrk reacted with thumbs up emoji

t.Run("LastUsed",func(t*testing.T) {
t.Parallel()
db,ps:=dbtestutil.NewDB(t,dbtestutil.WithTimezone("UTC"))
Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

review: LastUsed is apparentlyTIMESTAMP WITHOUT TIME ZONE. Not sure why this is.

Copy link
Member

@mafredrimafredriSep 14, 2023
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

There's no comment on the DB field explaining the reasoning, so it's definitely a bug.

The migration that added it made a mistake of usingtimestamp vstimestamptz.

000043_workspace_last_used.up.sql2:    ADD COLUMN last_used_at timestamp NOT NULL DEFAULT '0001-01-01 00:00:00+00:00';

(See conflict between default value and field type.)

We should probably lint this somehow and prevent addition oftimestamp columns unless//nolinted.

johnstcn and Emyrk reacted with thumbs up emoji
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Same bug inusers table withlast_seen_at.

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Filed#9682 to follow up.

mafredri reacted with heart emoji
Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

review: I initially had been setting a random timezone for each unit test, but I quickly found that way too chaotic to be useful.

It's more useful to pick random timezone once and going with that for all subsequent invocations. If things fail, they will at least fail consistently that run.

Emyrk reacted with thumbs up emoji
@johnstcnjohnstcn marked this pull request as ready for reviewSeptember 14, 2023 11:09
@mtojek
Copy link
Member

@johnstcn Could you please provide some description so we can see the reasoning behind it?

@johnstcn
Copy link
MemberAuthor

@johnstcn Could you please provide some description so we can see the reasoning behind it?

Updated description, you beat me in the data race :-)

mtojek reacted with laugh emoji

@spikecurtis
Copy link
Contributor

I think it's generally a lot better to have deterministic tests than stochastic ones. Flaky tests lower the teams trust in our test suite, and eat a lot of time.

In features that have dependencies on the database time zone, we should be adding (possibly exhaustive) test cases that use different time zones.

@johnstcn
Copy link
MemberAuthor

I think it's generally a lot better to have deterministic tests than stochastic ones. Flaky tests lower the teams trust in our test suite, and eat a lot of time.

In features that have dependencies on the database time zone, we should be adding (possibly exhaustive) test cases that use different time zones.

That's a good point. Instead, I can set to a fixed non-UTC timezone by default that does have a DST component, and keep the option of having a random timezone.

mafredri reacted with thumbs up emoji

Copy link
Member

@mafredrimafredri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Nice addition!

t.Logf("setting timezone of database %q to %q",dbname,tz)
// We apparently can't use placeholders here, sadly.
// nolint: gosec // This is not user input and this is only executed in tests
_,err=sqlDB.Exec(fmt.Sprintf("ALTER DATABASE %s SET TIMEZONE TO %q",dbname,tz))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

It's fine in tests, IMO. It's an unfortunate limitation of some PostgreSQL queries.

@johnstcnjohnstcn changed the titlefeat(coderd/database/dbtestutil): set a random timezone in the dbfeat(coderd/database/dbtestutil): set default database timezone to non-UTC in unit testsSep 14, 2023
require.NoError(t,err)

// Set the timezone for the database.
t.Logf("setting timezone of database %q to %q",dbname,tz)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

👍

@mtojekmtojek self-requested a reviewSeptember 14, 2023 14:59
Copy link
Member

@mtojekmtojek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Thanks for addressing the feedback!

…ld hopefully be greater than win32 max timer resolution
…t equal max_deadline" to actually be "deadline must not exceed max_deadline" as comments suggest
@johnstcnjohnstcn merged commit65db7a7 intomainSep 15, 2023
@johnstcnjohnstcn deleted the cj/dbtestutil-rand-tz branchSeptember 15, 2023 08:01
@github-actionsgithub-actionsbot locked and limited conversation to collaboratorsSep 15, 2023
Sign up for freeto subscribe to this conversation on GitHub. Already have an account?Sign in.
Reviewers

@mafredrimafredrimafredri left review comments

@EmyrkEmyrkEmyrk approved these changes

@mtojekmtojekmtojek approved these changes

@spikecurtisspikecurtisAwaiting requested review from spikecurtis

Assignees

@johnstcnjohnstcn

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

5 participants
@johnstcn@Emyrk@mtojek@spikecurtis@mafredri

[8]ページ先頭

©2009-2025 Movatter.jp