Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add rivertype.JobStates with full list of job states #297

Merged
merged 1 commit into from
Apr 16, 2024

Conversation

brandur
Copy link
Contributor

@brandur brandur commented Apr 14, 2024

Requested in #296, add a new JobStates() function that contains a
complete list of all JobState* constant values, which may be useful in
places like testing.

Also add a test that does a basic parsing of the corresponding Go file,
look for all JobState* values, and makes sure that JobStates()
contains every possible value to prevent future regressions.

Fixes #296.

@brandur brandur force-pushed the brandur-job-states branch 2 times, most recently from efcecae to 11bdd7b Compare April 14, 2024 23:41
@brandur brandur requested a review from bgentry April 14, 2024 23:44
@brandur brandur force-pushed the brandur-job-states branch 2 times, most recently from 493f653 to 7b8e838 Compare April 14, 2024 23:49
// they're included in JobStates. Helps check that we didn't add a new value
// but forgot to add it to the full list of constant values.
for _, nameAndValue := range allValuesForStringConstantType(t, "river_type.go", "JobState") {
t.Logf("Checking for job state: %s / %s", nameAndValue.Name, nameAndValue.Value)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

=== RUN   TestJobStates
=== PAUSE TestJobStates
=== CONT  TestJobStates
    river_type_test.go:27: Checking for job state: JobStateAvailable / available
    river_type_test.go:27: Checking for job state: JobStateCancelled / cancelled
    river_type_test.go:27: Checking for job state: JobStateCompleted / completed
    river_type_test.go:27: Checking for job state: JobStateDiscarded / discarded
    river_type_test.go:27: Checking for job state: JobStateRetryable / retryable
    river_type_test.go:27: Checking for job state: JobStateRunning / running
    river_type_test.go:27: Checking for job state: JobStateScheduled / scheduled
--- PASS: TestJobStates (0.00s)

@bgentry
Copy link
Contributor

bgentry commented Apr 15, 2024

Note that #301 adds a new pending state, so this function and its tests will need to be updated to include that new state. I've added a TODO to that PR for this.

Comment on lines +23 to +26
// Get all job state names from the corresponding source file and make sure
// they're included in JobStates. Helps check that we didn't add a new value
// but forgot to add it to the full list of constant values.
for _, nameAndValue := range allValuesForStringConstantType(t, "river_type.go", "JobState") {
Copy link
Contributor

Choose a reason for hiding this comment

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

Great idea!

}

if len(valueNames) < 1 {
require.FailNow(t, "Not values found", "No values found for source file and constant type: %s / %s", srcFile, typeName)
Copy link
Contributor

Choose a reason for hiding this comment

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

typo?

Suggested change
require.FailNow(t, "Not values found", "No values found for source file and constant type: %s / %s", srcFile, typeName)
require.FailNow(t, "No values found", "No values found for source file and constant type: %s / %s", srcFile, typeName)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yep, or probably Vim-o as I was trying to do something and accidentally added/replaced a character. Thanks!

@brandur
Copy link
Contributor Author

brandur commented Apr 15, 2024

Note that #301 adds a new pending state, so this function and its tests will need to be updated to include that new state. I've added a TODO to that PR for this.

Ah good to know. Welp, tests should fail, so hopefully we'll be forced to get this right.

Requested in #296, add a new `JobStates()` function that contains a
complete list of all `JobState*` constant values, which may be useful in
places like testing.

Also add a test that does a basic parsing of the corresponding Go file,
look for all `JobState*` values, and makes sure that `JobStates()`
contains every possible value to prevent future regressions.

Fixes #296.
@brandur
Copy link
Contributor Author

brandur commented Apr 16, 2024

Thx.

@brandur brandur merged commit 2985f68 into master Apr 16, 2024
10 checks passed
@brandur brandur deleted the brandur-job-states branch April 16, 2024 00:19
brandur added a commit that referenced this pull request Apr 16, 2024
Prep release of `v0.3.0`. This is a relatively small one containing
mainly #281 and #297, but I think it's not a bad idea to cut a release
since we haven't done one in a while, and to get these additive changes
out ahead of the number of breaking changes that'll probably come with
the next release.
@brandur brandur mentioned this pull request Apr 16, 2024
brandur added a commit that referenced this pull request Apr 16, 2024
Prep release of `v0.3.0`. This is a relatively small one containing
mainly #281 and #297, but I think it's not a bad idea to cut a release
since we haven't done one in a while, and to get these additive changes
out ahead of the number of breaking changes that'll probably come with
the next release.
@dhermes
Copy link
Contributor

dhermes commented Apr 16, 2024

Thanks for doing this @brandur! I was thinking you'd end up implementing this as something like a check against the output of \dT+ river_job_state. E.g. you could wire this query up with sqlc (thanks psql --echo-hidden!!):

SELECT
  n.nspname AS schema,
  e.enumlabel AS enum_value
FROM
  pg_catalog.pg_type AS t
  LEFT JOIN pg_catalog.pg_namespace AS n ON n.oid = t.typnamespace
  LEFT JOIN pg_catalog.pg_enum AS e ON e.enumtypid = t.oid
WHERE
  t.typname = 'river_job_state'
ORDER BY e.enumsortorder;

In our setup, where we put you guys in riverqueue schema, this produces

+------------+------------+
| schema     | enum_value |
|------------+------------|
| riverqueue | available  |
| riverqueue | cancelled  |
| riverqueue | completed  |
| riverqueue | discarded  |
| riverqueue | retryable  |
| riverqueue | running    |
| riverqueue | scheduled  |
+------------+------------+

I'm happy to implement this as a unit test if you'd like!

@bgentry
Copy link
Contributor

bgentry commented Apr 16, 2024

@dhermes this would be fine for a unit test, though I’m not sure it’s worth the effort. I wouldn’t want to base the actual API on that query though (not sure if this is what you were suggesting).

While I don’t expect to add more states beyond this, #301 does add a new pending state. If you were to deploy the new code but forget to run the migration, River’s API should still tell you what all the actual states are that it knows about IMO.

@dhermes
Copy link
Contributor

dhermes commented Apr 16, 2024

I wouldn't want to base the actual API on that query though (not sure if this is what you were suggesting).

Haha sorry I was not trying to suggest that. Definitely not.

this would be fine for a unit test, though I'm not sure it's worth the effort.

I've got some existing unit tests like this in our codebase that leverage sqlc so will be pretty low effort.

For me, it's just about trying to get the best of both worlds of Go and PostgreSQL. I.e. using the right native SQL / PostgreSQL capabilities for enums, and the right Go capabilities for enums. And then just making sure we have a guarantee at dev time that the native Go and native PostgreSQL are agreeing with each other.

If we're not aligned on this, all good. I'm not trying to step on any toes, it's your project! (And we love this project, it's awesome!)

brandur added a commit that referenced this pull request Apr 21, 2024
A small change that removes a list of all job states defined in
`insert_opts.go` that was used to validate states sent into `UniqueOpts`
with `rivertype.JobStates()` which was introduced recently n #297.
Removing one of the lists means we only need to maintain one of them.

I left the variable in place instead of invoking `rivertype.JobStates()`
so that we don't need to initialize a new slice every time we validate.
brandur added a commit that referenced this pull request May 2, 2024
A small change that removes a list of all job states defined in
`insert_opts.go` that was used to validate states sent into `UniqueOpts`
with `rivertype.JobStates()` which was introduced recently n #297.
Removing one of the lists means we only need to maintain one of them.

I left the variable in place instead of invoking `rivertype.JobStates()`
so that we don't need to initialize a new slice every time we validate.
brandur added a commit that referenced this pull request May 2, 2024
A small change that removes a list of all job states defined in
`insert_opts.go` that was used to validate states sent into `UniqueOpts`
with `rivertype.JobStates()` which was introduced recently n #297.
Removing one of the lists means we only need to maintain one of them.

I left the variable in place instead of invoking `rivertype.JobStates()`
so that we don't need to initialize a new slice every time we validate.
bgentry pushed a commit that referenced this pull request May 2, 2024
A small change that removes a list of all job states defined in
`insert_opts.go` that was used to validate states sent into `UniqueOpts`
with `rivertype.JobStates()` which was introduced recently n #297.
Removing one of the lists means we only need to maintain one of them.

I left the variable in place instead of invoking `rivertype.JobStates()`
so that we don't need to initialize a new slice every time we validate.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add func JobStates() []JobState in rivertype package
3 participants