Fix typos (#654)

CHANGELOG.md

@@ -333,7 +333,7 @@ river migrate-up --database-url "$DATABASE_URL"
 
 - **Breaking change:** There are a number of small breaking changes in the job list API using `JobList`/`JobListTx`:
   - Now support querying jobs by a list of Job Kinds and States. Also allows for filtering by specific timestamp values. Thank you Jos Kraaijeveld (@thatjos)! 🙏🏻 [PR #236](https://github.com/riverqueue/river/pull/236).
-  - Job listing now defaults to ordering by job ID (`JobListOrderByID`) instead of a job timestamp dependent on on requested job state. The previous ordering behavior is still available with `NewJobListParams().OrderBy(JobListOrderByTime, SortOrderAsc)`. [PR #307](https://github.com/riverqueue/river/pull/307).
+  - Job listing now defaults to ordering by job ID (`JobListOrderByID`) instead of a job timestamp dependent on requested job state. The previous ordering behavior is still available with `NewJobListParams().OrderBy(JobListOrderByTime, SortOrderAsc)`. [PR #307](https://github.com/riverqueue/river/pull/307).
   - The function `JobListCursorFromJob` no longer needs a sort order parameter. Instead, sort order is determined based on the job list parameters that the cursor is subsequently used with. [PR #307](https://github.com/riverqueue/river/pull/307).
 - **Breaking change:** Client `Insert` and `InsertTx` functions now return a `JobInsertResult` struct instead of a `JobRow`. This allows the result to include metadata like the new `UniqueSkippedAsDuplicate` property, so callers can tell whether an inserted job was skipped due to unique constraint. [PR #292](https://github.com/riverqueue/river/pull/292).
 - **Breaking change:** Client `InsertMany` and `InsertManyTx` now return number of jobs inserted as `int` instead of `int64`. This change was made to make the type in use a little more idiomatic. [PR #293](https://github.com/riverqueue/river/pull/293).
@@ -407,7 +407,7 @@ Although it comes with a number of improvements, there's nothing particularly no
 
 - Fixed a memory leak caused by allocating a new random source on every job execution. Thank you @shawnstephens for reporting ❤️ [PR #240](https://github.com/riverqueue/river/pull/240).
 - Fix a problem where `JobListParams.Queues()` didn't filter correctly based on its arguments. [PR #212](https://github.com/riverqueue/river/pull/212).
-- Fix a problem in `DebouncedChan` where it would fire on its "out" channel too often when it was being signaled continuousy on its "in" channel. This would have caused work to be fetched more often than intended in busy systems. [PR #222](https://github.com/riverqueue/river/pull/222).
+- Fix a problem in `DebouncedChan` where it would fire on its "out" channel too often when it was being signaled continuously on its "in" channel. This would have caused work to be fetched more often than intended in busy systems. [PR #222](https://github.com/riverqueue/river/pull/222).
 
 ## [0.0.22] - 2024-02-19
 
@@ -429,7 +429,7 @@ Although it comes with a number of improvements, there's nothing particularly no
 
 ### Added
 
-- Added an `ID` setting to the `Client` `Config` type to allow users to override client IDs with their own naming convention. Expose the client ID programatically (in case it's generated) in a new `Client.ID()` method. [PR #206](https://github.com/riverqueue/river/pull/206).
+- Added an `ID` setting to the `Client` `Config` type to allow users to override client IDs with their own naming convention. Expose the client ID programmatically (in case it's generated) in a new `Client.ID()` method. [PR #206](https://github.com/riverqueue/river/pull/206).
 
 ### Fixed
 
@@ -469,7 +469,7 @@ Although it comes with a number of improvements, there's nothing particularly no
 
 - Fixed incorrect default value handling for `ScheduledAt` option with `InsertMany` / `InsertManyTx`. [PR #149](https://github.com/riverqueue/river/pull/149).
 - Add missing `t.Helper()` calls in `rivertest` internal functions that caused it to report itself as the site of a test failure. [PR #151](https://github.com/riverqueue/river/pull/151).
-- Fixed problem where job uniqueness wasn't being respected when used in conjuction with periodic jobs. [PR #168](https://github.com/riverqueue/river/pull/168).
+- Fixed problem where job uniqueness wasn't being respected when used in conjunction with periodic jobs. [PR #168](https://github.com/riverqueue/river/pull/168).
 
 ## [0.0.16] - 2024-01-06
 
@@ -564,7 +564,7 @@ Although it comes with a number of improvements, there's nothing particularly no
 
 ### Changed
 
-- `JobRow`, `JobState`, and a other related types move into `river/rivertype` so they can more easily be shared amongst packages. Most of the River API doesn't change because `JobRow` is embedded on `river.Job`, which doesn't move.
+- `JobRow`, `JobState`, and other related types move into `river/rivertype` so they can more easily be shared amongst packages. Most of the River API doesn't change because `JobRow` is embedded on `river.Job`, which doesn't move.
 
 ## [0.0.5] - 2023-11-19
 
@@ -579,7 +579,7 @@ Although it comes with a number of improvements, there's nothing particularly no
 - Allow River clients to be created with a driver with `nil` database pool for use in testing.
 - Update River test helpers API to use River drivers like `riverdriver/riverpgxv5` to make them agnostic to the third party database package in use.
 - Document `Config.JobTimeout`'s default value.
-- Functionally disable the `Reindexer` queue maintenance service. It'd previously only operated on currently unused indexes anyway, indexes probably do _not_ need to be rebuilt except under fairly rare circumstances, and it needs more work to make sure it's shored up against edge cases like indexes that fail to rebuild before a clien restart.
+- Functionally disable the `Reindexer` queue maintenance service. It'd previously only operated on currently unused indexes anyway, indexes probably do _not_ need to be rebuilt except under fairly rare circumstances, and it needs more work to make sure it's shored up against edge cases like indexes that fail to rebuild before a client restart.
 
 ## [0.0.3] - 2023-11-13
 

client.go

@@ -97,7 +97,7 @@ type Config struct {
 
 	// FetchCooldown is the minimum amount of time to wait between fetches of new
 	// jobs. Jobs will only be fetched *at most* this often, but if no new jobs
-	// are coming in via LISTEN/NOTIFY then feches may be delayed as long as
+	// are coming in via LISTEN/NOTIFY then fetches may be delayed as long as
 	// FetchPollInterval.
 	//
 	// Throughput is limited by this value.
@@ -457,7 +457,7 @@ func NewClient[TTx any](driver riverdriver.Driver[TTx], config *Config) (*Client
 
 	// For convenience, in case the user's specified a large JobTimeout but no
 	// RescueStuckJobsAfter, since RescueStuckJobsAfter must be greater than
-	// JobTimeout, set a reasonable default value that's longer thah JobTimeout.
+	// JobTimeout, set a reasonable default value that's longer than JobTimeout.
 	rescueAfter := maintenance.JobRescuerRescueAfterDefault
 	if config.JobTimeout > 0 && config.RescueStuckJobsAfter < 1 && config.JobTimeout > config.RescueStuckJobsAfter {
 		rescueAfter = config.JobTimeout + maintenance.JobRescuerRescueAfterDefault
@@ -921,7 +921,7 @@ type SubscribeConfig struct {
 	// Requiring that kinds are specified explicitly allows for forward
 	// compatibility in case new kinds of events are added in future versions.
 	// If new event kinds are added, callers will have to explicitly add them to
-	// their requested list and esnure they can be handled correctly.
+	// their requested list and ensure they can be handled correctly.
 	Kinds []EventKind
 }
 
@@ -1059,7 +1059,7 @@ func (c *Client[TTx]) JobCancel(ctx context.Context, jobID int64) (*rivertype.Jo
 
 // JobCancelTx cancels the job with the given ID within the specified
 // transaction. This variant lets a caller cancel a job atomically alongside
-// other database changes. An cancelled job doesn't take effect until the
+// other database changes. A cancelled job doesn't take effect until the
 // transaction commits, and if the transaction rolls back, so too is the
 // cancelled job.
 //

cmd/river/rivercli/river_cli_test.go

@@ -107,7 +107,7 @@ func TestBaseCommandSetIntegration(t *testing.T) {
 		}
 	}
 
-	t.Run("DebugVerboseMutallyExclusive", func(t *testing.T) {
+	t.Run("DebugVerboseMutuallyExclusive", func(t *testing.T) {
 		t.Parallel()
 
 		cmd, _ := setup(t)

docs/README.md

@@ -178,7 +178,7 @@ See [developing River].
 
 ## Thank you
 
-River was in large part inspired by our experiences with other background job libaries over the years, most notably:
+River was in large part inspired by our experiences with other background job libraries over the years, most notably:
 
 - [Oban](https://github.com/sorentwo/oban) in Elixir.
 - [Que](https://github.com/que-rb/que), [Sidekiq](https://github.com/sidekiq/sidekiq), [Delayed::Job](https://github.com/collectiveidea/delayed_job), and [GoodJob](https://github.com/bensheldon/good_job) in Ruby.

insert_opts.go

@@ -157,7 +157,7 @@ type UniqueOpts struct {
 	// or `discarded`), though only `retryable` may be safely _removed_ from the
 	// list.
 	//
-	// Warning: Removing any states from the default list (other than `retryable`
+	// Warning: Removing any states from the default list (other than `retryable`)
 	// forces a fallback to a slower insertion path that takes an advisory lock
 	// and performs a look up before insertion. This path is deprecated and should
 	// be avoided if possible.

internal/jobcompleter/job_completer.go

@@ -514,7 +514,7 @@ func (c *BatchCompleter) waitOrInitBacklogChannel(ctx context.Context) {
 	c.Logger.WarnContext(ctx, c.Name+": Hit maximum backlog; completions will wait until below threshold", "max_backlog", c.maxBacklog)
 }
 
-// As configued, total time asleep from initial attempt is ~7 seconds (1 + 2 +
+// As configured, total time asleep from initial attempt is ~7 seconds (1 + 2 +
 // 4) (not including jitter). However, if each attempt times out, that's up to
 // ~37 seconds (7 seconds + 3 * 10 seconds).
 const numRetries = 3

internal/leadership/elector.go

@@ -316,7 +316,7 @@ func (e *Elector) keepLeadershipLoop(ctx context.Context) error {
 			return ctx.Err()
 
 		case <-timer.C:
-			// Reelect timer expired; attempt releection below.
+			// Reelect timer expired; attempt reelection below.
 
 		case <-e.leadershipNotificationChan:
 			// Used only in tests for force an immediately reelect attempt.
@@ -463,7 +463,7 @@ func (e *Elector) tryUnlisten(sub *Subscription) bool {
 	return false
 }
 
-// leaderTTL is at least the relect run interval used by clients to try and gain
+// leaderTTL is at least the reelect run interval used by clients to try and gain
 // leadership or reelect themselves as leader, plus a little padding to account
 // to give the leader a little breathing room in its reelection loop.
 func (e *Elector) leaderTTL() time.Duration {

internal/maintenance/job_rescuer.go

@@ -43,7 +43,7 @@ func (ts *JobRescuerTestSignals) Init() {
 
 type JobRescuerConfig struct {
 	// ClientRetryPolicy is the default retry policy to use for workers that don't
-	// overide NextRetry.
+	// override NextRetry.
 	ClientRetryPolicy ClientRetryPolicy
 
 	// Interval is the amount of time to wait between runs of the rescuer.

internal/maintenance/queue_maintainer.go

@@ -138,7 +138,7 @@ func (s *queueMaintainerServiceBase) StaggerStartupIsDisabled() bool {
 }
 
 // withStaggerStartupDisable is an interface to a service whose stagger startup
-// sleep can be disable.
+// sleep can be disabled.
 type withStaggerStartupDisable interface {
 	// StaggerStartupDisable sets whether the short staggered sleep on start up
 	// is disabled. This is useful in tests where the extra sleep involved in a

internal/notifier/notifier_test.go

@@ -480,7 +480,7 @@ func TestNotifier(t *testing.T) {
 
 		start(t, notifier)
 
-		// The service normally sleeps with a exponential backoff after an
+		// The service normally sleeps with an exponential backoff after an
 		// error, but we've disabled sleep above, so we can pull errors out of
 		// the test signal as quickly as we want.
 		require.EqualError(t, notifier.testSignals.BackoffError.WaitOrTimeout(), "error during wait 1")

internal/riverinternaltest/riverdrivertest/riverdrivertest.go

@@ -2767,7 +2767,7 @@ func Exercise[TTx any](ctx context.Context, t *testing.T,
 			tBefore := time.Now().UTC()
 			queueBefore, err := exec.QueueCreateOrSetUpdatedAt(ctx, &riverdriver.QueueCreateOrSetUpdatedAtParams{
 				Metadata:  metadata,
-				Name:      "updateable-queue",
+				Name:      "updatable-queue",
 				UpdatedAt: &tBefore,
 			})
 			require.NoError(t, err)
@@ -2776,15 +2776,15 @@ func Exercise[TTx any](ctx context.Context, t *testing.T,
 			tAfter := tBefore.Add(2 * time.Second)
 			queueAfter, err := exec.QueueCreateOrSetUpdatedAt(ctx, &riverdriver.QueueCreateOrSetUpdatedAtParams{
 				Metadata:  []byte(`{"other": "metadata"}`),
-				Name:      "updateable-queue",
+				Name:      "updatable-queue",
 				UpdatedAt: &tAfter,
 			})
 			require.NoError(t, err)
 
 			// unchanged:
 			require.Equal(t, queueBefore.CreatedAt, queueAfter.CreatedAt)
 			require.Equal(t, metadata, queueAfter.Metadata)
-			require.Equal(t, "updateable-queue", queueAfter.Name)
+			require.Equal(t, "updatable-queue", queueAfter.Name)
 			require.Nil(t, queueAfter.PausedAt)
 
 			// Timestamp is bumped:

internal/riverinternaltest/riverinternaltest.go

@@ -29,7 +29,7 @@ import (
 // always end up in a `retryable` state rather than `available`. Normally, the
 // job executor sets `available` if the retry delay is smaller than the
 // scheduler's interval. To simplify things so errors are always `retryable`,
-// this time is picked to be smaller than the any retry delay that the default
+// this time is picked to be smaller than any retry delay that the default
 // retry policy will ever produce. It's shared so we can document/explain it all
 // in one place.
 const SchedulerShortInterval = 500 * time.Millisecond

internal/util/hashutil/hash_util_test.go

@@ -31,7 +31,7 @@ func TestAdvisoryLockHash(t *testing.T) {
 		// The output hash isn't guaranteed to be larger than MaxInt32 of
 		// course, but given a reasonable hash function like FNV that produces
 		// good distribution, it's far more likely to be than not. We're using a
-		// fixed input in this test, so we know that it always be in this case.
+		// fixed input in this test, so we know that it'll always be in this case.
 		require.Greater(t, int(key), math.MaxInt32)
 	})
 }

job_args_reflect_kind_test.go

@@ -24,7 +24,7 @@ import "reflect"
 //
 // We're not sure yet whether it's appropriate to expose this publicly, so for
 // now we've localized it to the test suite only. When a test case needs a job
-// type that won't be reused, its preferrable to make use of JobArgsReflectKind
+// type that won't be reused, it's preferable to make use of JobArgsReflectKind
 // so the type doesn't pollute the global namespace.
 type JobArgsReflectKind[TKind any] struct{}
 

producer.go

@@ -54,7 +54,7 @@ type producerConfig struct {
 
 	// FetchCooldown is the minimum amount of time to wait between fetches of new
 	// jobs. Jobs will only be fetched *at most* this often, but if no new jobs
-	// are coming in via LISTEN/NOTIFY then feches may be delayed as long as
+	// are coming in via LISTEN/NOTIFY then fetches may be delayed as long as
 	// FetchPollInterval.
 	FetchCooldown time.Duration
 
@@ -206,7 +206,7 @@ func newProducer(archetype *baseservice.Archetype, exec riverdriver.Executor, co
 //
 // This variant uses a single context as fetchCtx and workCtx, and is here to
 // implement startstop.Service so that the producer can be stored as a service
-// variable and used with various serviec utilties. StartWorkContext below
+// variable and used with various service utilities. StartWorkContext below
 // should be preferred for production use.
 func (p *producer) Start(ctx context.Context) error {
 	return p.StartWorkContext(ctx, ctx)
@@ -514,7 +514,7 @@ func (p *producer) maybeCancelJob(id int64) {
 }
 
 func (p *producer) dispatchWork(workCtx context.Context, count int, fetchResultCh chan<- producerFetchResult) {
-	// This intentionally removes any deadlines or cancelleation from the parent
+	// This intentionally removes any deadlines or cancellation from the parent
 	// context because we don't want it to get cancelled if the producer is asked
 	// to shut down. In that situation, we want to finish fetching any jobs we are
 	// in the midst of fetching, work them, and then stop. Otherwise we'd have a

retry_policy.go

@@ -47,7 +47,7 @@ type DefaultClientRetryPolicy struct {
 func (p *DefaultClientRetryPolicy) NextRetry(job *rivertype.JobRow) time.Time {
 	// For the purposes of calculating the backoff, we can look solely at the
 	// number of errors. If we were to use the raw attempt count, this would be
-	// incemented and influenced by snoozes. However the use case for snoozing is
+	// incremented and influenced by snoozes. However the use case for snoozing is
 	// to try again later *without* counting as an error.
 	//
 	// Note that we explicitly add 1 here, because the error hasn't been appended

riverdriver/riverdatabasesql/internal/pgtypealias/pgtype_alias.go

@@ -1,4 +1,4 @@
-// package pgtypealias exists to work aronud sqlc bugs with being able to
+// package pgtypealias exists to work around sqlc bugs with being able to
 // reference v5 the pgtype package from within a dbsql package.
 package pgtypealias
 

riverdriver/riverdatabasesql/migration/main/002_initial_schema.up.sql

@@ -66,7 +66,7 @@ DECLARE
   payload json;
 BEGIN
   IF NEW.state = 'available' THEN
-    -- Notify will coalesce duplicate notificiations within a transaction, so
+    -- Notify will coalesce duplicate notifications within a transaction, so
     -- keep these payloads generalized:
     payload = json_build_object('queue', NEW.queue);
     PERFORM

riverdriver/riverdatabasesql/migration/main/004_pending_and_more.down.sql

@@ -18,7 +18,7 @@ DECLARE
   payload json;
 BEGIN
   IF NEW.state = 'available' THEN
-    -- Notify will coalesce duplicate notificiations within a transaction, so
+    -- Notify will coalesce duplicate notifications within a transaction, so
     -- keep these payloads generalized:
     payload = json_build_object('queue', NEW.queue);
     PERFORM

riverdriver/riverdatabasesql/migration/main/006_bulk_unique.up.sql

@@ -22,7 +22,7 @@ $$;
 --
 ALTER TABLE river_job ADD COLUMN unique_states BIT(8);
 
--- This statements uses `IF NOT EXISTS` to allow users with a `river_job` table
+-- This statement uses `IF NOT EXISTS` to allow users with a `river_job` table
 -- of non-trivial size to build the index `CONCURRENTLY` out of band of this
 -- migration, then follow by completing the migration.
 CREATE UNIQUE INDEX IF NOT EXISTS river_job_unique_idx ON river_job (unique_key)

riverdriver/riverpgxv5/migration/main/002_initial_schema.up.sql

@@ -66,7 +66,7 @@ DECLARE
   payload json;
 BEGIN
   IF NEW.state = 'available' THEN
-    -- Notify will coalesce duplicate notificiations within a transaction, so
+    -- Notify will coalesce duplicate notifications within a transaction, so
     -- keep these payloads generalized:
     payload = json_build_object('queue', NEW.queue);
     PERFORM

riverdriver/riverpgxv5/migration/main/004_pending_and_more.down.sql

@@ -18,7 +18,7 @@ DECLARE
   payload json;
 BEGIN
   IF NEW.state = 'available' THEN
-    -- Notify will coalesce duplicate notificiations within a transaction, so
+    -- Notify will coalesce duplicate notifications within a transaction, so
     -- keep these payloads generalized:
     payload = json_build_object('queue', NEW.queue);
     PERFORM

riverdriver/riverpgxv5/migration/main/006_bulk_unique.up.sql

@@ -22,7 +22,7 @@ $$;
 --
 ALTER TABLE river_job ADD COLUMN unique_states BIT(8);
 
--- This statements uses `IF NOT EXISTS` to allow users with a `river_job` table
+-- This statement uses `IF NOT EXISTS` to allow users with a `river_job` table
 -- of non-trivial size to build the index `CONCURRENTLY` out of band of this
 -- migration, then follow by completing the migration.
 CREATE UNIQUE INDEX IF NOT EXISTS river_job_unique_idx ON river_job (unique_key)

riverdriver/riverpgxv5/river_pgx_v5_driver.go

@@ -751,7 +751,7 @@ func (l *Listener) Close(ctx context.Context) error {
 
 	// Release below would take care of cleanup and potentially put the
 	// connection back into rotation, but in case a Listen was invoked without a
-	// subsequent Unlisten on the same tpic, close the connection explicitly to
+	// subsequent Unlisten on the same topic, close the connection explicitly to
 	// guarantee no other caller will receive a partially tainted connection.
 	err := l.conn.Conn().Close(ctx)