enhancement: add context management support to storages #1569
Conversation
efectn
requested review from
ReneWerner87,
gaby and
sixcolors
and removed request for
a team
|
""" WalkthroughA comprehensive refactor has been applied across many storage driver packages to add context-aware operations. The standard Get, Set, Delete, and Reset methods have been replaced or extended with versions that accept a context parameter, allowing cancellation and timeout handling. Existing methods now delegate to these new implementations using a background context, ensuring backward compatibility while improving concurrent operation management. Test suites have been updated to simulate context cancellations and validate proper error handling. Minor changes include configuration updates and HTTP request modifications to ensure context propagation. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant Storage
Client->>Storage: Call Get(key) / Set(key, val, exp)
Storage->>Storage: Create background context
Storage->>Storage: Call GetWithContext(ctx, key) / SetWithContext(ctx, key, val, exp)
Storage-->>Client: Return value or error (context canceled if applicable)
Possibly related PRs
Suggested reviewers
Poem
✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (6)
mssql/mssql_test.go (1)
13-18:⚠️ Potential issueFix test initialization failure in CI pipeline.
The test initialization fails in the CI pipeline, likely due to missing environment variables or connection issues.
Consider these improvements:
- Add environment variable validation:
var testStore = New(Config{ + // Fail fast if required environment variables are not set + Database: func() string { + db := os.Getenv("MSSQL_DATABASE") + if db == "" { + panic("MSSQL_DATABASE environment variable is required") + } + return db + }(), + Username: func() string { + user := os.Getenv("MSSQL_USERNAME") + if user == "" { + panic("MSSQL_USERNAME environment variable is required") + } + return user + }(), - Database: os.Getenv("MSSQL_DATABASE"), - Username: os.Getenv("MSSQL_USERNAME"), Password: os.Getenv("MSSQL_PASSWORD"), Reset: true, })
- Add a test skip when running in CI:
+func init() { + if os.Getenv("CI") != "" && os.Getenv("MSSQL_DATABASE") == "" { + fmt.Println("Skipping MSSQL tests in CI environment") + os.Exit(0) + } +}🧰 Tools
🪛 GitHub Actions: Benchmark
[error] 13-13: Initialization failed in mssql_test.go.
mssql/mssql.go (1)
93-95:⚠️ Potential issueReplace panic with proper error handling in New function.
Panicking on connection failure makes error handling difficult for consumers and could cause issues in production.
- if err := db.Ping(); err != nil { - panic(err) - } + if err := db.Ping(); err != nil { + _ = db.Close() + return nil, fmt.Errorf("failed to connect to MSSQL: %w", err) + }This requires updating the function signature:
-func New(config ...Config) *Storage { +func New(config ...Config) (*Storage, error) {And updating the test initialization:
var testStore *Storage func init() { store, err := New(Config{ Database: os.Getenv("MSSQL_DATABASE"), Username: os.Getenv("MSSQL_USERNAME"), Password: os.Getenv("MSSQL_PASSWORD"), Reset: true, }) if err != nil { if os.Getenv("CI") != "" { fmt.Printf("Skipping MSSQL tests: %v\n", err) os.Exit(0) } panic(err) } testStore = store }🧰 Tools
🪛 GitHub Actions: Benchmark
[error] 94-94: Panic occurred: read tcp 127.0.0.1:49246->127.0.0.1:1433: read: connection reset by peer.
azureblob/azureblob.go (1)
158-163: 🛠️ Refactor suggestionConsider returning errors instead of panicking.
The
handleErrorhelper function panics on configuration errors. Consider returning these errors to allow better error handling by the caller.-func handleError(err error) { - if err != nil { - panic(fmt.Sprintf("invalid config:, %v", err)) - } +func handleError(err error) error { + if err != nil { + return fmt.Errorf("invalid config: %w", err) + } + return nil }valkey/valkey.go (1)
67-67:⚠️ Potential issueFix the benchmark pipeline failure.
The benchmark is failing due to a Redis connection refused error. This suggests that Redis is not running or not accessible during the benchmark test.
Please ensure that Redis is properly configured and running in the CI environment before running the benchmarks. You might need to:
- Add Redis service to the GitHub Actions workflow
- Wait for Redis to be ready before running the benchmarks
- Verify the Redis connection settings
🧰 Tools
🪛 GitHub Actions: Benchmark
[error] 67-67: Panic occurred: dial tcp 127.0.0.1:6379: connect: connection refused
dynamodb/dynamodb_test.go (1)
14-23:⚠️ Potential issueFix DynamoDB test configuration.
The test is failing with
ResourceNotFoundException. Ensure the table exists before running the tests.❌ Verification inconclusive
🏁 Script executed:
#!/bin/bash # Create DynamoDB table for tests aws dynamodb create-table \ --table-name fiber_storage \ --attribute-definitions AttributeName=id,AttributeType=S \ --key-schema AttributeName=id,KeyType=HASH \ --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \ --endpoint-url http://localhost:8000Length of output: 351
DynamoDB Table Creation Fails Due to Missing AWS CLI
The supplied shell script intended to create the table isn't executing because the AWS CLI isn't installed in the current environment. Please ensure you run the table-creation command in an environment where the AWS CLI is available (or install/configure it in your test setup) so that the "fiber_storage" table exists before the tests are executed.
minio/minio_test.go (1)
334-334: 💡 Verification agent🧩 Analysis chain
Docker pull rate limit affecting benchmarks.
The benchmarks are failing due to Docker pull rate limits. Consider:
- Authenticating with Docker Hub
- Using GitHub Container Registry as a fallback
- Caching the container image
Also applies to: 345-345, 362-362
🏁 Script executed:
#!/bin/bash # Check if GitHub Container Registry has the minio image gh api \ -H "Accept: application/vnd.oci.image.index.v1+json" \ /v2/minio/minio/tags/listLength of output: 393
Action Required: Docker Hub Auth & Fallback for Image Pulls Not Implemented
The API call to GitHub Container Registry failed with an unsupported Accept header, confirming the fallback isn’t configured as intended. The benchmark code still appears to trigger Docker pulls without authentication or caching, leading to rate limit failures.
- The attempted fallback check using an incorrect header (should use
application/json) failed.- No changes addressing authentication with Docker Hub or image caching were detected in the affected benchmark sections.
Please update the Docker image handling by authenticating to Docker Hub, correctly querying GitHub Container Registry (using
application/jsonin the Accept header), and caching the container image to avoid pull rate limits.🧰 Tools
🪛 GitHub Actions: Benchmark
[error] 334-334: Received unexpected error: create container: Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit
🧹 Nitpick comments (16)
sqlite3/sqlite3_test.go (1)
27-191: Consider adding more test cases for context-aware operations.While the current tests cover context cancellation scenarios well, consider adding:
- Positive test cases with non-canceled context
- Timeout test cases using
context.WithTimeout- Test cases with parent context cancellation
Example for SetWithContext positive case:
func Test_SQLite3_SetWithContext_Success(t *testing.T) { var ( key = "john" val = []byte("doe") ) ctx := context.Background() err := testStore.SetWithContext(ctx, key, val, 0) require.NoError(t, err) result, err := testStore.Get(key) require.NoError(t, err) require.Equal(t, val, result) }sqlite3/sqlite3.go (2)
122-134: Consider adding context cancellation handling.While the context is correctly passed to database operations, consider adding explicit error checks for context cancellation to provide more specific error messages.
Example implementation for SetWithContext:
func (s *Storage) SetWithContext(ctx context.Context, key string, val []byte, exp time.Duration) error { + if err := ctx.Err(); err != nil { + return fmt.Errorf("context error in SetWithContext: %w", err) + } // Ain't Nobody Got Time For That if len(key) <= 0 || len(val) <= 0 { return nil }Also applies to: 141-149, 156-160
187-190: Consider adding context support to garbage collection.The gc operation could benefit from context management to handle timeouts and cancellations during cleanup operations, especially for large datasets.
This could be implemented in a future update by:
- Adding a context parameter to the gc method
- Using ExecContext instead of Exec
- Propagating the context through the gcTicker
mssql/mssql_test.go (1)
30-41: Enhance test coverage for SetWithContext.The test verifies the error case but doesn't confirm that the value wasn't actually set in the database.
func Test_MSSQL_SetWithContext(t *testing.T) { var ( key = "john" val = []byte("doe") ) ctx, cancel := context.WithCancel(context.Background()) cancel() err := testStore.SetWithContext(ctx, key, val, 0) require.ErrorIs(t, err, context.Canceled) + + // Verify the value wasn't set + result, err := testStore.Get(key) + require.NoError(t, err) + require.Zero(t, len(result)) }mssql/mssql.go (3)
136-163: Enhance GetWithContext documentation and validation.The implementation is correct but could benefit from improved documentation and validation.
-// GetWithContext gets value by key with context +// GetWithContext gets value by key with context. +// Returns nil, ctx.Err() if the context is canceled or times out. +// Returns nil, nil if the key doesn't exist or is expired. func (s *Storage) GetWithContext(ctx context.Context, key string) ([]byte, error) { + if ctx == nil { + ctx = context.Background() + } + if len(key) <= 0 { return nil, nil }
170-183: Enhance SetWithContext documentation and validation.The implementation is correct but could benefit from improved documentation and validation.
-// SetWithContext key with value and expiration time with context +// SetWithContext sets a key-value pair with an optional expiration time. +// Returns ctx.Err() if the context is canceled or times out. +// The operation is atomic; if the context is canceled, the value won't be set. func (s *Storage) SetWithContext(ctx context.Context, key string, val []byte, exp time.Duration) error { + if ctx == nil { + ctx = context.Background() + } + if len(key) <= 0 || len(val) <= 0 { return nil }
241-244: Add context support to garbage collection.The gc method should support context for graceful shutdown and preventing long-running operations.
-func (s *Storage) gc(t time.Time) { +func (s *Storage) gc(ctx context.Context, t time.Time) { - _, _ = s.db.Exec(s.sqlGC, t.Unix()) + _, _ = s.db.ExecContext(ctx, s.sqlGC, t.Unix()) } func (s *Storage) gcTicker() { ticker := time.NewTicker(s.gcInterval) defer ticker.Stop() + ctx, cancel := context.WithCancel(context.Background()) + defer cancel() + for { select { case <-s.done: return case t := <-ticker.C: - s.gc(t) + s.gc(ctx, t) } } }valkey/valkey_test.go (2)
27-38: Enhance context-aware test coverage.While the current tests verify canceled context behavior, consider adding tests for:
- Context timeout scenarios
- Parent context propagation
- Non-canceled context success cases
Here's an example of additional test cases:
+func Test_Valkey_SetWithContextTimeout(t *testing.T) { + var ( + key = "john" + val = []byte("doe") + ) + + ctx, cancel := context.WithTimeout(context.Background(), 1*time.Nanosecond) + defer cancel() + time.Sleep(1 * time.Millisecond) // Ensure timeout + + err := testStore.SetWithContext(ctx, key, val, 0) + require.ErrorIs(t, err, context.DeadlineExceeded) +} + +func Test_Valkey_SetWithContextSuccess(t *testing.T) { + var ( + key = "john" + val = []byte("doe") + ) + + ctx := context.Background() + err := testStore.SetWithContext(ctx, key, val, 0) + require.NoError(t, err) + + // Verify the value was set + result, err := testStore.Get(key) + require.NoError(t, err) + require.Equal(t, val, result) +}Also applies to: 67-82, 128-146, 169-191
315-352: Add benchmarks for context-aware operations and improve test organization.Consider the following improvements:
- Add benchmarks for context-aware operations
- Use table-driven tests with t.Run for better organization
Here's an example of a context-aware benchmark:
+func Benchmark_Valkey_SetWithContext(b *testing.B) { + b.ReportAllocs() + b.ResetTimer() + + ctx := context.Background() + var err error + for i := 0; i < b.N; i++ { + err = testStore.SetWithContext(ctx, "john", []byte("doe"), 0) + } + + require.NoError(b, err) +}And here's how to organize tests using sub-tests:
+func Test_Valkey_Set_Operations(t *testing.T) { + tests := []struct { + name string + key string + value []byte + exp time.Duration + wantErr bool + }{ + { + name: "basic set", + key: "john", + value: []byte("doe"), + exp: 0, + wantErr: false, + }, + // Add more test cases + } + + for _, tt := range tests { + t.Run(tt.name, func(t *testing.T) { + err := testStore.Set(tt.key, tt.value, tt.exp) + if tt.wantErr { + require.Error(t, err) + return + } + require.NoError(t, err) + }) + } +}etcd/etcd.go (1)
95-102: Consider adding error documentation.While the implementation is correct, consider documenting the possible errors that could be returned from the etcd Delete operation.
clickhouse/clickhouse.go (1)
79-112: Consider simplifying the time comparison logic.The time comparison logic is complex and includes a comment about inconsistent behavior. Consider extracting this logic into a helper function for better maintainability.
+func isExpired(t time.Time) bool { + return !time.Unix(0, 0).Equal(t) && t.Before(time.Now().UTC()) +} func (s *Storage) GetWithContext(ctx context.Context, key string) ([]byte, error) { // ... existing code ... - if !time.Unix(0, 0).Equal(result.Expiration) && result.Expiration.Before(time.Now().UTC()) { + if isExpired(result.Expiration) { return []byte{}, nil } // ... existing code ... }azureblob/azureblob.go (1)
111-113: Review commented-out code.There's commented-out code for container deletion. Either remove it or document why it's kept as a reference.
- //_, err := s.client.DeleteContainer(ctx, s.container, nil) - //return errcloudflarekv/cloudflarekv.go (1)
110-157: Consider adding pagination size limit.While the implementation of
ResetWithContextis good, consider adding a limit to the number of keys retrieved in each pagination request to prevent potential memory issues with large datasets.resp, err := s.api.ListWorkersKVKeys(ctx, cloudflare.AccountIdentifier(s.accountID), cloudflare.ListWorkersKVsParams{ NamespaceID: s.namespaceID, Cursor: cursor, + Limit: 1000, // Add reasonable pagination size })cloudflarekv/cloudflarekv_test.go (1)
70-70: Remove debug print statement.Remove the
fmt.Println(err)statement as it's not needed in the test.-fmt.Println(err)arangodb/arangodb_test.go (1)
174-174: Maintain consistency in error checking style.Consider using
require.NoError(t, err)instead ofrequire.Equal(t, err, nil)to maintain consistency with other tests.- require.Equal(t, err, nil) + require.NoError(t, err)dynamodb/dynamodb.go (1)
163-169: Consider using BatchWriteItem for Reset operation.The current implementation deletes and recreates the table, which might not be ideal for production environments due to:
- Potential permission issues (requires table deletion rights)
- Downtime during table recreation
- Loss of table configuration (indexes, capacity settings)
Consider using BatchWriteItem to delete items in batches instead:
-func (s *Storage) ResetWithContext(ctx context.Context) error { - deleteTableInput := awsdynamodb.DeleteTableInput{ - TableName: &s.table, - } - _, err := s.db.DeleteTable(ctx, &deleteTableInput) - return err +func (s *Storage) ResetWithContext(ctx context.Context) error { + scanInput := &awsdynamodb.ScanInput{ + TableName: &s.table, + AttributesToGet: []string{keyAttrName}, + } + + var lastKey map[string]types.AttributeValue + for { + scanInput.ExclusiveStartKey = lastKey + result, err := s.db.Scan(ctx, scanInput) + if err != nil { + return err + } + + if len(result.Items) > 0 { + writeRequests := make([]types.WriteRequest, len(result.Items)) + for i, item := range result.Items { + writeRequests[i] = types.WriteRequest{ + DeleteRequest: &types.DeleteRequest{ + Key: item, + }, + } + } + + batchInput := &awsdynamodb.BatchWriteItemInput{ + RequestItems: map[string][]types.WriteRequest{ + s.table: writeRequests, + }, + } + + if _, err := s.db.BatchWriteItem(ctx, batchInput); err != nil { + return err + } + } + + lastKey = result.LastEvaluatedKey + if lastKey == nil { + break + } + } + + return nil +}
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (39)
arangodb/README.md(1 hunks)arangodb/arangodb.go(3 hunks)arangodb/arangodb_test.go(5 hunks)azureblob/azureblob.go(2 hunks)azureblob/azureblob_test.go(5 hunks)clickhouse/clickhouse.go(4 hunks)clickhouse/clickhouse_test.go(4 hunks)cloudflarekv/cloudflarekv.go(6 hunks)cloudflarekv/cloudflarekv_test.go(4 hunks)cloudflarekv/test_module.go(5 hunks)dynamodb/dynamodb.go(5 hunks)dynamodb/dynamodb_test.go(5 hunks)etcd/etcd.go(3 hunks)etcd/etcd_test.go(4 hunks)minio/minio.go(6 hunks)minio/minio_test.go(4 hunks)mongodb/mongodb.go(3 hunks)mongodb/mongodb_test.go(5 hunks)mssql/mssql.go(4 hunks)mssql/mssql_test.go(5 hunks)mysql/mysql.go(4 hunks)mysql/mysql_test.go(5 hunks)nats/config.go(1 hunks)nats/nats.go(10 hunks)nats/nats_test.go(6 hunks)postgres/postgres.go(3 hunks)postgres/postgres_test.go(4 hunks)redis/redis.go(1 hunks)redis/redis_test.go(5 hunks)rueidis/rueidis.go(1 hunks)rueidis/rueidis_test.go(5 hunks)s3/s3.go(5 hunks)s3/s3_test.go(5 hunks)scylladb/scylladb.go(5 hunks)scylladb/scylladb_test.go(5 hunks)sqlite3/sqlite3.go(4 hunks)sqlite3/sqlite3_test.go(5 hunks)valkey/valkey.go(1 hunks)valkey/valkey_test.go(5 hunks)
🧰 Additional context used
🪛 GitHub Actions: Benchmark
mssql/mssql.go
[error] 94-94: Panic occurred: read tcp 127.0.0.1:49246->127.0.0.1:1433: read: connection reset by peer.
valkey/valkey_test.go
[error] 13-13: Initialization failed in valkey_test.go due to connection issue.
mssql/mssql_test.go
[error] 13-13: Initialization failed in mssql_test.go.
minio/minio_test.go
[error] 334-334: Received unexpected error: create container: Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit
[error] 345-345: Received unexpected error: create container: Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit
[error] 362-362: Received unexpected error: create container: Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit
valkey/valkey.go
[error] 67-67: Panic occurred: dial tcp 127.0.0.1:6379: connect: connection refused
🪛 GitHub Actions: Tests DynamoDB
dynamodb/dynamodb_test.go
[error] 162-162: Received unexpected error: operation error DynamoDB: PutItem, https response error StatusCode: 400, RequestID: 2e1849af-f3c3-45c7-9a07-d99ee1d1192c, ResourceNotFoundException.
🔇 Additional comments (137)
sqlite3/sqlite3_test.go (5)
4-4: LGTM: Context import added for new test functions.The context import is correctly added to support the new context-aware test functions.
27-38: LGTM: SetWithContext test implementation.The test correctly verifies context cancellation behavior for the Set operation.
67-82: LGTM: GetWithContext test implementation.The test properly verifies context cancellation behavior and empty result for the Get operation.
128-146: LGTM: DeleteWithContext test implementation.The test effectively verifies context cancellation behavior and data persistence for the Delete operation.
169-191: LGTM: ResetWithContext test implementation.The test thoroughly verifies context cancellation behavior and data persistence for the Reset operation.
sqlite3/sqlite3.go (3)
4-4: LGTM!The context import is correctly added and properly ordered.
92-115: LGTM! GetWithContext implementation is robust.The implementation correctly uses QueryRowContext and handles all edge cases including:
- Empty key validation
- SQL no rows error
- Expiration time check
117-120: LGTM! Original methods correctly delegate to context-aware versions.The implementation maintains backward compatibility while leveraging the new context-aware methods. The use of context.Background() is appropriate for these default methods.
Also applies to: 136-139, 151-154, 162-165
mssql/mssql_test.go (3)
70-85: LGTM! Thorough test coverage.The test effectively verifies both the error condition and the empty result when the context is canceled.
131-149: LGTM! Comprehensive test coverage.The test effectively verifies both the error condition and data persistence when the context is canceled.
172-194: LGTM! Thorough test coverage.The test effectively verifies both the error condition and data persistence for multiple values when the context is canceled.
valkey/valkey_test.go (1)
13-15: Investigate initialization failure in CI pipeline.The pipeline is reporting initialization failures for the test store. This could be due to connection issues with the underlying storage service.
Run the following script to check if the service is properly configured and accessible:
❌ Verification inconclusive
🏁 Script executed:
#!/bin/bash # Description: Check if the storage service is accessible # Note: Using netcat to check port availability echo "Checking default port..." nc -zv localhost 6379 2>&1 echo "Checking TLS port..." nc -zv localhost 6380 2>&1 echo "Checking cluster ports..." for port in {7000..7005}; do nc -zv localhost $port 2>&1 doneLength of output: 1274
Investigate missing connectivity diagnostic tool in CI environment.
- The connectivity check script failed because the
nc(netcat) command is not installed on the CI runner.- Due to this, we cannot verify if the storage service ports (6379, 6380, 7000-7005) are accessible, which might be contributing to the initialization failure of the test store.
- Please consider either installing netcat in the CI environment or using an alternative connectivity check (e.g., using bash’s
/dev/tcpmechanism) to validate service accessibility.🧰 Tools
🪛 GitHub Actions: Benchmark
[error] 13-13: Initialization failed in valkey_test.go due to connection issue.
nats/config.go (1)
25-26: LGTM! Clear and well-documented addition.The new
Resetfield in theConfigstruct is well-documented and maintains backward compatibility with its default value offalse.etcd/etcd.go (3)
35-49: LGTM! Well-implemented context support for Get operation.The implementation correctly handles empty keys and properly uses the context in the etcd operation.
55-72: LGTM! Robust implementation of Set with context.The implementation includes proper validation and correctly uses context for both lease grant and put operations.
78-89: LGTM! Clean implementation of Delete with context.The implementation includes proper validation and correctly uses context in the delete operation.
clickhouse/clickhouse.go (1)
53-73: LGTM! Well-structured Set implementation with context.The implementation includes proper validation and correctly uses context in the database operation.
azureblob/azureblob.go (1)
150-156: LGTM! Well-implemented timeout management.The
requestContexthelper function provides a clean way to handle request timeouts with proper cleanup through cancel functions.redis/redis.go (8)
78-88: LGTM! Well-implemented context support for Get operation.The implementation correctly handles context propagation while preserving the existing error handling and empty key validation.
90-93: LGTM! Proper backward compatibility.The original Get method maintains backward compatibility by delegating to GetWithContext with a background context.
95-101: LGTM! Well-implemented context support for Set operation.The implementation correctly handles context propagation while preserving the existing error handling and empty key/value validation.
103-106: LGTM! Proper backward compatibility.The original Set method maintains backward compatibility by delegating to SetWithContext with a background context.
108-114: LGTM! Well-implemented context support for Delete operation.The implementation correctly handles context propagation while preserving the existing error handling and empty key validation.
116-119: LGTM! Proper backward compatibility.The original Delete method maintains backward compatibility by delegating to DeleteWithContext with a background context.
121-124: LGTM! Well-implemented context support for Reset operation.The implementation correctly handles context propagation.
126-129: LGTM! Proper backward compatibility.The original Reset method maintains backward compatibility by delegating to ResetWithContext with a background context.
rueidis/rueidis.go (8)
88-98: LGTM! Well-implemented context support for Get operation with caching.The implementation correctly handles context propagation while preserving the existing error handling, empty key validation, and cache TTL configuration.
100-103: LGTM! Proper backward compatibility.The original Get method maintains backward compatibility by delegating to GetWithContext with a background context.
105-115: LGTM! Well-implemented context support for Set operation.The implementation correctly handles context propagation while preserving the existing error handling, empty key/value validation, and expiration logic.
117-120: LGTM! Proper backward compatibility.The original Set method maintains backward compatibility by delegating to SetWithContext with a background context.
122-128: LGTM! Well-implemented context support for Delete operation.The implementation correctly handles context propagation while preserving the existing error handling and empty key validation.
130-133: LGTM! Proper backward compatibility.The original Delete method maintains backward compatibility by delegating to DeleteWithContext with a background context.
135-138: LGTM! Well-implemented context support for Reset operation.The implementation correctly handles context propagation.
140-143: LGTM! Proper backward compatibility.The original Reset method maintains backward compatibility by delegating to ResetWithContext with a background context.
valkey/valkey.go (8)
88-98: LGTM! Well-implemented context support for Get operation with caching.The implementation correctly handles context propagation while preserving the existing error handling, empty key validation, and cache TTL configuration.
100-103: LGTM! Proper backward compatibility.The original Get method maintains backward compatibility by delegating to GetWithContext with a background context.
105-115: LGTM! Well-implemented context support for Set operation.The implementation correctly handles context propagation while preserving the existing error handling, empty key/value validation, and expiration logic.
117-120: LGTM! Proper backward compatibility.The original Set method maintains backward compatibility by delegating to SetWithContext with a background context.
122-128: LGTM! Well-implemented context support for Delete operation.The implementation correctly handles context propagation while preserving the existing error handling and empty key validation.
130-133: LGTM! Proper backward compatibility.The original Delete method maintains backward compatibility by delegating to DeleteWithContext with a background context.
135-138: LGTM! Well-implemented context support for Reset operation.The implementation correctly handles context propagation.
140-143: LGTM! Proper backward compatibility.The original Reset method maintains backward compatibility by delegating to ResetWithContext with a background context.
s3/s3_test.go (4)
20-31: LGTM! Well-implemented test for SetWithContext.The test correctly verifies context cancellation behavior for the Set operation.
60-75: LGTM! Well-implemented test for GetWithContext.The test correctly verifies:
- Context cancellation behavior
- Error handling
- Empty result on cancellation
100-118: LGTM! Well-implemented test for DeleteWithContext.The test correctly verifies:
- Context cancellation behavior
- Error handling
- Data persistence on cancellation
141-163: LGTM! Well-implemented test for ResetWithContext.The test correctly verifies:
- Context cancellation behavior
- Error handling
- Data persistence on cancellation
etcd/etcd_test.go (4)
53-64: LGTM! Well-structured test for context cancellation.The test properly verifies that
SetWithContexthandles context cancellation correctly.
66-81: LGTM! Comprehensive test for GetWithContext.The test effectively verifies both the error condition and the nil result when context is canceled.
106-119: LGTM! Thorough test for DeleteWithContext.The test properly verifies that the operation is canceled and the data remains unchanged.
132-145: LGTM! Complete test for ResetWithContext.The test effectively verifies context cancellation and data preservation.
cloudflarekv/cloudflarekv.go (3)
58-71: LGTM! Clean implementation of context-aware Get methods.Good pattern of implementing
GetWithContextand havingGetdelegate to it with a background context.
73-90: LGTM! Well-structured context-aware Set methods.Good implementation of
SetWithContextand delegation pattern inSet.
92-108: LGTM! Proper implementation of context-aware Delete methods.Good pattern of implementing
DeleteWithContextand havingDeletedelegate to it.cloudflarekv/cloudflarekv_test.go (1)
92-103: LGTM! Comprehensive context cancellation tests.The tests for
SetWithContext,DeleteWithContext, andResetWithContextare well-structured and verify both the cancellation error and data preservation.Also applies to: 122-140, 152-174
dynamodb/dynamodb_test.go (1)
41-52: LGTM! Well-structured context cancellation tests.The tests for context-aware methods are comprehensive and verify both cancellation errors and data preservation.
Also applies to: 81-92, 117-135, 158-180
minio/minio.go (1)
65-86: Well-implemented context management support!The implementation follows best practices:
- Each operation has a WithContext variant
- Original methods delegate to WithContext versions with background context
- Context is properly propagated to underlying MinIO operations
- Error handling is consistent across all methods
Also applies to: 88-91, 93-111, 113-116, 118-128, 130-133, 135-160, 162-164
mongodb/mongodb_test.go (1)
35-46: Excellent test coverage for context-aware operations!The tests thoroughly verify:
- Context cancellation handling
- Error propagation
- Data integrity after failed operations
Also applies to: 75-90, 136-154, 177-199
scylladb/scylladb_test.go (1)
23-34: Well-structured tests maintaining consistency across storage implementations!The tests follow the same robust pattern as other storage implementations, ensuring:
- Proper context cancellation handling
- Error type verification
- Data consistency checks
Also applies to: 72-87, 130-148, 171-193
arangodb/arangodb_test.go (1)
25-36: Well-implemented tests following the established pattern!The tests maintain consistency with other storage implementations, providing thorough coverage of:
- Context cancellation scenarios
- Error propagation
- Data integrity verification
Also applies to: 65-80, 126-144, 167-189
azureblob/azureblob_test.go (4)
46-61: LGTM! Well-structured test for context cancellation.The test effectively validates the behavior of
GetWithContextwhen the context is canceled, ensuring proper error propagation.
73-84: LGTM! Well-structured test for context cancellation.The test effectively validates the behavior of
SetWithContextwhen the context is canceled, ensuring proper error propagation.
108-126: LGTM! Comprehensive test for context cancellation.The test effectively validates the behavior of
DeleteWithContextwhen the context is canceled, including verification that the data remains intact after the failed deletion.
183-205: LGTM! Comprehensive test for context cancellation.The test effectively validates the behavior of
ResetWithContextwhen the context is canceled, including verification that all data remains intact after the failed reset.postgres/postgres.go (4)
100-124: LGTM! Well-implemented context support.The function correctly uses
QueryRowContextand handles all edge cases appropriately.
143-155: LGTM! Well-implemented context support.The function correctly uses
ExecContextand handles all edge cases appropriately.
162-170: LGTM! Well-implemented context support.The function correctly uses
ExecContextand handles all edge cases appropriately.
177-181: LGTM! Well-implemented context support.The function correctly uses
ExecContextfor the reset operation.mysql/mysql.go (4)
109-136: LGTM! Well-implemented context support.The function correctly uses
QueryRowContextand handles all edge cases appropriately.
143-155: LGTM! Well-implemented context support.The function correctly uses
ExecContextand handles all edge cases appropriately.
162-170: LGTM! Well-implemented context support.The function correctly uses
ExecContextand handles all edge cases appropriately.
177-181: LGTM! Well-implemented context support.The function correctly uses
ExecContextfor the reset operation.scylladb/scylladb.go (4)
137-147: LGTM! Well-implemented context support.The function correctly uses
WithContextand handles all edge cases appropriately.
154-161: LGTM! Well-implemented context support.The function correctly uses
WithContextand handles expiration appropriately.
168-171: LGTM! Well-implemented context support.The function correctly uses
WithContextfor the delete operation.
178-181: LGTM! Well-implemented context support.The function correctly uses
WithContextfor the reset operation.mongodb/mongodb.go (8)
124-150: LGTM!The implementation correctly uses the context parameter in the FindOne operation and handles errors appropriately.
152-155: LGTM!The function maintains backward compatibility by delegating to GetWithContext with a background context.
157-179: LGTM!The implementation correctly uses the context parameter in the ReplaceOne operation and properly handles upsert functionality.
181-187: LGTM!The function maintains backward compatibility by delegating to SetWithContext with a background context.
189-197: LGTM!The implementation correctly uses the context parameter in the DeleteOne operation and handles empty key checks.
199-202: LGTM!The function maintains backward compatibility by delegating to DeleteWithContext with a background context.
204-207: LGTM!The implementation correctly uses the context parameter in the Drop operation.
209-212: LGTM!The function maintains backward compatibility by delegating to ResetWithContext with a background context.
postgres/postgres_test.go (4)
30-41: LGTM!The test correctly verifies that SetWithContext handles context cancellation.
70-85: LGTM!The test correctly verifies that GetWithContext handles context cancellation and returns appropriate results.
131-145: LGTM!The test correctly verifies that DeleteWithContext handles context cancellation.
168-190: LGTM!The test correctly verifies that ResetWithContext handles context cancellation and maintains data integrity.
cloudflarekv/test_module.go (5)
57-57: LGTM!The function correctly uses NewRequestWithContext for context-aware HTTP request creation.
98-98: LGTM!The function correctly uses NewRequestWithContext for context-aware HTTP request creation.
137-137: LGTM!The function correctly uses NewRequestWithContext for context-aware HTTP request creation.
176-176: LGTM!The function correctly uses NewRequestWithContext for context-aware HTTP request creation.
228-228: LGTM!The function correctly uses NewRequestWithContext for context-aware HTTP request creation.
s3/s3.go (8)
81-100: LGTM!The implementation correctly uses the context parameter in the Download operation and handles errors appropriately.
102-108: LGTM!The function maintains backward compatibility by delegating to GetWithContext with a timeout-aware context.
110-123: LGTM!The implementation correctly uses the context parameter in the Upload operation and handles empty key checks.
125-131: LGTM!The function maintains backward compatibility by delegating to SetWithContext with a timeout-aware context.
133-145: LGTM!The implementation correctly uses the context parameter in the DeleteObject operation and handles empty key checks.
147-153: LGTM!The function maintains backward compatibility by delegating to DeleteWithContext with a timeout-aware context.
155-186: LGTM!The implementation correctly uses the context parameter in both ListObjectsV2Paginator and DeleteObjects operations, with proper pagination handling.
188-194: LGTM!The function maintains backward compatibility by delegating to ResetWithContext with a timeout-aware context.
mysql/mysql_test.go (4)
61-72: LGTM! Well-structured context cancellation test.The test correctly verifies that SetWithContext fails with context.Canceled when the context is canceled before the operation.
70-89: LGTM! Comprehensive context cancellation test.The test thoroughly verifies GetWithContext behavior by:
- Setting up test data
- Verifying context.Canceled error
- Ensuring empty result on cancellation
134-156: LGTM! Thorough deletion verification with context.The test effectively verifies that:
- DeleteWithContext fails with context.Canceled
- The data remains intact after the failed deletion
178-204: LGTM! Comprehensive reset verification with context.The test effectively verifies that:
- ResetWithContext fails with context.Canceled
- Multiple keys remain intact after the failed reset
arangodb/arangodb.go (4)
119-150: LGTM! Well-implemented context-aware Get operation.The implementation correctly:
- Uses context for all database operations
- Handles document existence check
- Manages expiration logic
158-191: LGTM! Robust context-aware Set operation.The implementation correctly:
- Uses context for all database operations
- Handles document existence and updates
- Manages expiration time calculation
199-206: LGTM! Clean context-aware Delete operation.The implementation correctly:
- Uses context for the database operation
- Includes proper input validation
214-216: LGTM! Concise context-aware Reset operation.The implementation correctly uses context for the truncate operation.
dynamodb/dynamodb.go (3)
80-105: LGTM! Well-implemented context-aware Get operation.The implementation correctly:
- Uses context for DynamoDB operations
- Handles ResourceNotFoundException
- Unmarshals the result properly
112-132: LGTM! Robust context-aware Set operation.The implementation correctly:
- Uses context for DynamoDB operations
- Includes input validation
- Constructs DynamoDB attributes properly
139-156: LGTM! Clean context-aware Delete operation.The implementation correctly:
- Uses context for DynamoDB operations
- Includes input validation
- Constructs delete request properly
rueidis/rueidis_test.go (4)
27-42: LGTM! Well-structured context cancellation test.The test correctly verifies that SetWithContext fails with context.Canceled when the context is canceled before the operation.
70-89: LGTM! Comprehensive context cancellation test.The test thoroughly verifies GetWithContext behavior by:
- Setting up test data
- Verifying context.Canceled error
- Ensuring empty result on cancellation
134-156: LGTM! Thorough deletion verification with context.The test effectively verifies that:
- DeleteWithContext fails with context.Canceled
- The data remains intact after the failed deletion
178-204: LGTM! Comprehensive reset verification with context.The test effectively verifies that:
- ResetWithContext fails with context.Canceled
- Multiple keys remain intact after the failed reset
clickhouse/clickhouse_test.go (4)
79-93: LGTM! Test verifies context cancellation for SetWithContext.The test correctly verifies that a canceled context prevents the operation and returns the expected error.
121-139: LGTM! Test verifies context cancellation for GetWithContext.The test correctly verifies that a canceled context prevents the operation, returns the expected error, and ensures no value is returned.
186-208: LGTM! Test verifies context cancellation for DeleteWithContext.The test correctly verifies that a canceled context prevents the operation, returns the expected error, and ensures the value remains accessible.
232-254: LGTM! Test verifies context cancellation for ResetWithContext.The test correctly verifies that a canceled context prevents the operation, returns the expected error, and ensures values remain accessible.
nats/nats.go (5)
37-50: LGTM! Initialization uses background context.The function correctly uses a background context for initialization, ensuring proper setup of the NATS key-value store.
169-204: LGTM! Get operations properly handle context.The implementation correctly:
- Adds context support through GetWithContext
- Maintains backward compatibility through Get
- Includes proper error handling
207-249: LGTM! Set operations properly handle context.The implementation correctly:
- Adds context support through SetWithContext
- Maintains backward compatibility through Set
- Includes proper error handling
252-271: LGTM! Delete operations properly handle context.The implementation correctly:
- Adds context support through DeleteWithContext
- Maintains backward compatibility through Delete
- Includes proper error handling
274-306: LGTM! Reset operations properly handle context.The implementation correctly:
- Adds context support through ResetWithContext
- Maintains backward compatibility through Reset
- Includes proper error handling
minio/minio_test.go (4)
80-98: LGTM! Test verifies context cancellation for GetWithContext.The test correctly verifies that a canceled context prevents the operation and returns the expected error.
156-170: LGTM! Test verifies context cancellation for SetWithContext.The test correctly verifies that a canceled context prevents the operation and returns the expected error.
221-242: LGTM! Test verifies context cancellation for DeleteWithContext.The test correctly verifies that a canceled context prevents the operation and returns the expected error.
297-320: LGTM! Test verifies context cancellation for ResetWithContext.The test correctly verifies that a canceled context prevents the operation and returns the expected error.
nats/nats_test.go (4)
44-61: LGTM! Test verifies context cancellation for SetWithContext.The test correctly verifies that a canceled context prevents the operation and returns the expected error.
106-127: LGTM! Test verifies context cancellation for GetWithContext.The test correctly verifies that a canceled context prevents the operation and returns the expected error.
224-250: LGTM! Test verifies context cancellation for DeleteWithContext.The test correctly verifies that a canceled context prevents the operation and returns the expected error.
283-315: LGTM! Test verifies context cancellation for ResetWithContext.The test correctly verifies that a canceled context prevents the operation and returns the expected error.
redis/redis_test.go (4)
26-40: LGTM! Test correctly verifies context cancellation for Set operation.The test properly validates that a canceled context prevents the Set operation and returns the expected context.Canceled error.
83-101: LGTM! Test correctly verifies context cancellation for Get operation.The test effectively:
- Sets up test data
- Verifies that a canceled context prevents retrieval
- Confirms zero-length result on failure
160-181: LGTM! Test correctly verifies context cancellation for Delete operation.The test properly:
- Sets up test data
- Verifies that a canceled context prevents deletion
- Confirms data persistence after failed deletion
215-244: LGTM! Test correctly verifies context cancellation for Reset operation.The test effectively:
- Sets up multiple test entries
- Verifies that a canceled context prevents reset
- Confirms data persistence after failed reset
arangodb/README.md (1)
26-33: LGTM! Documentation properly reflects the new context-aware methods.The signatures section correctly documents all new context-aware methods while maintaining the existing method documentation.
|
think it would make sense to put everything in a new branch for v3 and upgrade everyone to the latest version of the dependencies and only support the latest go version
|
Agree with this plan. We should also make note that we will only support the latest 2 versions of Go going forward. |
|
i just created v3 branch |
|
I had a short chat with @efectn since it is just an extension of the interface and no breaking changes, we leave the target on main and do the rest testcontainers, version update, dependencie update in a followup task this makes sense because the storages can also be used independently of the fiber web framework @coderabbitai please create a cleanup task as a new issue so that we do not forget it
|
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain@ReneWerner87 I've created a new issue tracking the cleanup tasks as requested. The issue includes all the specified tasks along with proper context about its relationship to the current PR and future Fiber v3 integration. Let me know if you'd like any adjustments to the issue. 🏁 Script executed: Length of output: 988 @ReneWerner87 I've created issue #1570 tracking all the cleanup tasks. The issue has been assigned to you and includes all the specified tasks along with proper context. Let me know if you need any adjustments to the issue. ✏️ Learnings added
If you found this review helpful, would you consider giving us a shout-out on X? |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
couchbase/couchbase.go (1)
114-116: Consider adding context support to Close methodFor consistency with the other methods, consider adding a
CloseWithContextmethod that accepts a context parameter, and refactor the existingClosemethod to use it with a background context.+ func (s *Storage) CloseWithContext(ctx context.Context) error { + return s.cb.Close(&gocb.ClusterCloseOptions{ + Context: ctx, + }) + } func (s *Storage) Close() error { - return s.cb.Close(nil) + return s.CloseWithContext(context.Background()) }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
couchbase/couchbase.go(3 hunks)couchbase/couchbase_test.go(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (17)
- GitHub Check: Tests (1.20.x, 7.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.21.x)
- GitHub Check: Tests (1.21.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.22.x)
- GitHub Check: Tests (1.20.x)
- GitHub Check: Tests (1.20.x)
- GitHub Check: Tests (1.22.x)
- GitHub Check: Tests (1.21.x)
- GitHub Check: Tests (1.22.x)
- GitHub Check: Tests (1.21.x)
- GitHub Check: Tests (1.19.x)
- GitHub Check: Tests (1.19.x)
- GitHub Check: Tests (1.21.x)
- GitHub Check: Tests (1.20.x)
- GitHub Check: Tests (1.21.x)
🔇 Additional comments (10)
couchbase/couchbase_test.go (1)
65-75: Good addition of context cancellation testThis test validates that the
SetWithContextmethod properly handles context cancellation, which is essential for ensuring the reliability of context-aware operations. The test creates a context with a very short timeout to simulate context cancellation and verifies that an error is returned.couchbase/couchbase.go (9)
4-4: Correctly added context importThe addition of the context package import is necessary for implementing the context-aware methods.
47-70: Well-implemented GetWithContext methodThe
GetWithContextimplementation correctly integrates context support with Couchbase operations. It preserves the original error handling logic while allowing timeout and cancellation control through the provided context.
72-74: Good refactoring of Get methodThe
Getmethod has been properly refactored to callGetWithContextwith a background context, maintaining backward compatibility while leveraging the new context-aware implementation.
76-85: Well-implemented SetWithContext methodThe
SetWithContextimplementation correctly passes the context to the Couchbase operation. This allows for better control over timeouts and cancellations during write operations.
87-89: Good refactoring of Set methodThe
Setmethod has been cleanly refactored to callSetWithContextwith a background context, maintaining backward compatibility.
91-98: Well-implemented DeleteWithContext methodThe
DeleteWithContextimplementation correctly incorporates context support for delete operations, allowing for better control over timeouts and cancellations.
100-102: Good refactoring of Delete methodThe
Deletemethod has been effectively refactored to useDeleteWithContextwith a background context, maintaining backward compatibility.
104-108: Well-implemented ResetWithContext methodThe
ResetWithContextimplementation correctly passes the context to the bucket flush operation, enabling timeout and cancellation control for this potentially long-running operation.
110-112: Good refactoring of Reset methodThe
Resetmethod has been properly refactored to callResetWithContextwith a background context, maintaining backward compatibility.
|
Hi @mdelapenya. When i run couchbase tests with testcontainers-go, a timeout error raises after 30 seconds, especially with context tests; however, when i run tests with couchbase image on docker, everything works well. Do you have an idea why? I also run into the same issue for neo4j storage. Thanks |
|
@mdelapenya can you support here , do you know the reason ? |
|
Sorry, I read the ping today 🤦 When we merged the couchbase module, we needed to increase the max timeout of the go test command to 600s. I can imagine the differences running couchbase with plain docker come from the lack of a consistent wait strategy: if you just "docker run" the couchbase image, does it have a healthcheck to wait for it? In TC we wait for the cluster to be ready (see https://github.com/testcontainers/testcontainers-go/blob/3298e9a4d9c48615715f892e8e6e5505384270aa/modules/couchbase/couchbase.go#L189) I'd suggest increasing the go test timeout to 300s (in the benchmarks it was higher because of the load, my guess). Please increase that test timeout in your IDE settings too (I do it in my VSCode/Cursor) |
|
@efectn is it fine if I add some commits on top of yours updating the tests? |
Yes of course, feel free to play. |
|
@efectn I think there are no more compile-error, so the failures seem related to the changes in this PR. See https://github.com/gofiber/storage/actions/runs/14128624646/job/39583343922?pr=1569#step:4:53 |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (19)
badger/badger.go (3)
98-102: Context functionality is not implemented.Similar to
GetWithContext, this method provides only interface compliance without actual context support. Set operations will not respect context cancellation or timeouts.
115-119: Context functionality is not implemented.Delete operations will not respect context cancellation or timeouts with this dummy implementation.
126-130: Context functionality is not implemented.Reset operations will not respect context cancellation or timeouts with this dummy implementation.
ristretto/ristretto.go (3)
75-78: Context functionality is not implemented.Similar to other methods, this provides only interface compliance without actual context support.
89-92: Context functionality is not implemented.Delete operations will not respect context cancellation or timeouts.
100-103: Context functionality is not implemented.Reset operations will not respect context cancellation or timeouts.
bbolt/bbolt.go (4)
66-69: Context functionality is not implemented.The dummy context implementation means context cancellation, timeouts, and deadlines will not be respected. This appears to be for interface compliance only.
83-86: Context functionality is not implemented.Similar to other methods, this provides only interface compliance without actual context support.
100-103: Context functionality is not implemented.Delete operations will not respect context cancellation or timeouts.
115-118: Context functionality is not implemented.Reset operations will not respect context cancellation or timeouts.
memcache/memcache.go (4)
72-75: Context functionality is not implemented.The dummy context implementation means that memcache operations will not respect context cancellation, timeouts, or deadlines.
94-97: Context functionality is not implemented.Set operations will not respect context cancellation or timeouts with this dummy implementation.
107-110: Context functionality is not implemented.Delete operations will not respect context cancellation or timeouts.
117-120: Context functionality is not implemented.Reset operations will not respect context cancellation or timeouts.
pebble/pebble.go (4)
77-80: Context functionality is not implemented.The dummy context implementation means that Get operations will not respect context cancellation, timeouts, or deadlines.
105-108: Context functionality is not implemented.Set operations will not respect context cancellation or timeouts with this dummy implementation.
118-121: Context functionality is not implemented.Delete operations will not respect context cancellation or timeouts.
128-131: Context functionality is not implemented.Reset operations will not respect context cancellation or timeouts.
memory/memory.go (1)
59-62: Consider actual context utilization in future iterations.The dummy context support is acceptable for interface compliance, but consider implementing actual context checking for consistency with other storage backends that support cancellation.
For now, the implementation is correct for in-memory operations which are typically fast and don't benefit from cancellation.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
badger/badger.go(4 hunks)bbolt/bbolt.go(4 hunks)memcache/memcache.go(4 hunks)memory/memory.go(7 hunks)mockstorage/mockstorage.go(7 hunks)mockstorage/mockstorage_test.go(2 hunks)pebble/pebble.go(4 hunks)ristretto/ristretto.go(4 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (16)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.24.x, 8)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.21.x)
- GitHub Check: Tests (1.20.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.22.x)
- GitHub Check: Tests (1.21.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
🔇 Additional comments (20)
badger/badger.go (1)
76-80: Context cancellation and timeouts will not work with this implementation.The
GetWithContextmethod currently ignores the context parameter and delegates to the originalGetmethod. This means context cancellation, timeouts, and deadlines will not be respected.While this appears to be intentional based on the comment, consider if Badger operations could benefit from context support in the future, especially for long-running transactions or when implementing timeout behavior.
ristretto/ristretto.go (1)
56-59: Context cancellation and timeouts will not work.The dummy context implementation means that context cancellation, timeouts, and deadlines will not be respected. While this appears intentional for interface compliance, it limits the effectiveness of context-aware operations.
memcache/memcache.go (1)
132-132: Good comment improvement.The change from "Release item from pool" to "Release item back to pool" improves clarity.
pebble/pebble.go (2)
57-59: Good improvement to resource management.Adding explicit
closer.Close()before unmarshalling ensures proper resource cleanup and is a good practice when working with Pebble iterators.
88-92: Formatting improvement.The restructured
CacheTypeinitialization improves readability.memory/memory.go (4)
4-4: LGTM: Context import added for new interface compliance.The context import is necessary for the new context-aware method signatures.
21-23: LGTM: Minor formatting improvements.The field alignment and comment clarification improve code readability.
52-52: LGTM: Parentheses fix improves readability.The parentheses around the expiry condition make the logic clearer to read.
82-85: LGTM: Consistent dummy context pattern across all CRUD operations.All context-aware methods follow the same pattern of delegating to the original methods, maintaining consistency with the GetWithContext implementation.
Also applies to: 98-101, 112-115
mockstorage/mockstorage_test.go (5)
5-5: LGTM: Context import added for new test functions.The context import is necessary for the new context-aware test methods.
279-302: LGTM: Comprehensive test for GetWithContext.The test properly validates both fallback behavior to the original Get method and custom override functionality. Good use of different context values to verify the custom function is actually called.
304-330: LGTM: Thorough SetWithContext test with error handling.The test validates fallback behavior and includes proper error handling verification for the custom override case. The verification of the set value confirms the fallback actually works.
332-359: LGTM: Complete DeleteWithContext test coverage.The test verifies both successful deletion through fallback and error handling through custom override. The validation that the key is actually deleted is important.
361-385: LGTM: Solid ResetWithContext test implementation.The test follows the established pattern and properly validates both reset functionality and custom error handling.
mockstorage/mockstorage.go (6)
4-4: LGTM: Context import for new interface methods.The context import is required for the new context-aware method signatures.
30-41: LGTM: Well-structured extension of CustomFuncs.The addition of context-aware function fields maintains consistency with the existing pattern and provides comprehensive mock customization capabilities.
46-48: LGTM: Constructor improvement eliminates nil checks.Initializing CustomFuncs with an empty struct is cleaner than leaving it nil and eliminates the need to check for nil in the method implementations.
77-83: LGTM: Consistent context-aware method pattern.The GetWithContext implementation follows a clean pattern: check for custom function first, then fallback to the original method. This provides maximum flexibility for testing scenarios.
103-109: LGTM: Consistent implementation across all context-aware methods.All context-aware methods follow the same pattern as GetWithContext, providing consistent behavior and testing capabilities across the entire interface.
Also applies to: 123-129, 143-149
191-191: LGTM: Updated comment for clarity.The comment better describes the method's purpose for runtime function injection.
There was a problem hiding this comment.
Actionable comments posted: 8
🔭 Outside diff range comments (1)
cassandra/cassandra.go (1)
268-297: Fix inconsistent context usage in expired key cleanup.The
GetWithContextmethod properly uses the provided context for the main query, but the expired key deletion on line 290 ignores the context by callings.Delete(key)instead ofs.DeleteWithContext(ctx, key).Apply this fix to ensure consistent context propagation:
// Check if the key has expired if !result.ExpiresAt.IsZero() && time.Now().After(result.ExpiresAt) { // Delete the expired key - if err := s.Delete(key); err != nil { + if err := s.DeleteWithContext(ctx, key); err != nil { return nil, err } return nil, ErrKeyExpired }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
aerospike/aerospike.go(5 hunks)cassandra/cassandra.go(6 hunks)cassandra/cassandra_test.go(4 hunks)surrealdb/surrealdb.go(7 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (60)
- GitHub Check: lint (postgres)
- GitHub Check: Tests (1.24.x, 7)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.24.x, 8)
- GitHub Check: lint (postgres)
- GitHub Check: Tests (1.24.x, 7)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.24.x, 8)
- GitHub Check: Tests (1.22.x)
- GitHub Check: lint (postgres)
- GitHub Check: Tests (1.24.x, 7)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.24.x, 8)
- GitHub Check: Tests (1.22.x)
- GitHub Check: lint (postgres)
- GitHub Check: Tests (1.24.x, 7)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.24.x, 8)
- GitHub Check: Tests (1.22.x)
- GitHub Check: lint (postgres)
- GitHub Check: Tests (1.24.x, 7)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.24.x, 8)
- GitHub Check: Tests (1.22.x)
- GitHub Check: lint (postgres)
- GitHub Check: Tests (1.24.x, 7)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.24.x, 8)
- GitHub Check: Tests (1.22.x)
- GitHub Check: lint (postgres)
- GitHub Check: lint (mssql)
- GitHub Check: Tests (1.24.x, 7)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.24.x, 8)
- GitHub Check: Tests (1.22.x)
- GitHub Check: lint (postgres)
- GitHub Check: lint (mssql)
- GitHub Check: Tests (1.24.x, 7)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.24.x, 8)
- GitHub Check: Tests (1.22.x)
- GitHub Check: lint (postgres)
- GitHub Check: lint (mssql)
- GitHub Check: Tests (1.24.x, 7)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x, 8)
- GitHub Check: Tests (1.22.x)
- GitHub Check: lint (mssql)
- GitHub Check: Tests (1.24.x, 7)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x, 8)
- GitHub Check: Tests (1.22.x)
🔇 Additional comments (14)
cassandra/cassandra_test.go (4)
69-83: LGTM! Well-structured context cancellation test.The test correctly verifies that
SetWithContextrespects context cancellation and returns the appropriate error while ensuring no side effects occur on the storage.
105-125: LGTM! Comprehensive context cancellation test for Get operation.The test properly sets up data first, then verifies that
GetWithContextwith a canceled context returns the expected error while leaving the underlying data intact.
151-175: LGTM! Thorough context cancellation test for Delete operation.The test establishes the key exists, verifies
DeleteWithContextfails with canceled context, and confirms the key remains undeleted - excellent coverage of the expected behavior.
247-272: LGTM! Complete context cancellation test for Reset operation.The test correctly verifies that
ResetWithContextrespects context cancellation by ensuring both test keys remain in storage after the canceled operation.cassandra/cassandra.go (8)
4-4: LGTM! Required import for context support.The context import is necessary for the new context-aware storage methods.
222-261: LGTM! Well-implemented context-aware Set method.The
SetWithContextmethod properly integrates context support by passing it through to the underlying gocqlx query execution viaWithContext(ctx).
263-266: LGTM! Clean refactor maintaining backward compatibility.The original
Setmethod correctly delegates toSetWithContextwith a background context, preserving existing behavior while enabling context support.
299-302: LGTM! Clean refactor maintaining backward compatibility.The original
Getmethod correctly delegates toGetWithContextwith a background context.
304-315: LGTM! Well-implemented context-aware Delete method.The
DeleteWithContextmethod properly integrates context support into the gocqlx query execution.
317-321: LGTM! Clean refactor maintaining backward compatibility.The original
Deletemethod correctly delegates toDeleteWithContextwith a background context.
323-328: LGTM! Well-implemented context-aware Reset method.The
ResetWithContextmethod properly passes the context through to the underlying query execution.
330-334: LGTM! Clean refactor maintaining backward compatibility.The original
Resetmethod correctly delegates toResetWithContextwith a background context, maintaining existing behavior.aerospike/aerospike.go (1)
4-4: Context import added for dummy implementations.The context package is imported but the new context-aware methods don't actually utilize the context for cancellation, deadlines, or request tracing.
surrealdb/surrealdb.go (1)
4-4: Context and time imports added for enhanced functionality.The imports support the new context-aware methods and time-based operations.
Also applies to: 7-7
Add WithContext methods to storage.go
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
README.md (1)
29-62: Fix markdown formatting: Replace hard tabs with spaces.The markdown linter has flagged multiple lines using hard tabs instead of spaces, which violates markdown formatting standards.
Apply this formatting fix to replace hard tabs with spaces throughout the interface documentation:
- // GetWithContext gets the value for the given key with a context. - // `nil, nil` is returned when the key does not exist - GetWithContext(ctx context.Context, key string) ([]byte, error) + // GetWithContext gets the value for the given key with a context. + // `nil, nil` is returned when the key does not exist + GetWithContext(ctx context.Context, key string) ([]byte, error)Similar replacements should be applied to all other lines flagged by the linter (lines 29-62).
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
README.md(1 hunks)storage.go(1 hunks)
🧰 Additional context used
🪛 markdownlint-cli2 (0.17.2)
README.md
29-29: Hard tabs
Column: 1
(MD010, no-hard-tabs)
30-30: Hard tabs
Column: 1
(MD010, no-hard-tabs)
31-31: Hard tabs
Column: 1
(MD010, no-hard-tabs)
33-33: Hard tabs
Column: 1
(MD010, no-hard-tabs)
34-34: Hard tabs
Column: 1
(MD010, no-hard-tabs)
35-35: Hard tabs
Column: 1
(MD010, no-hard-tabs)
37-37: Hard tabs
Column: 1
(MD010, no-hard-tabs)
38-38: Hard tabs
Column: 1
(MD010, no-hard-tabs)
39-39: Hard tabs
Column: 1
(MD010, no-hard-tabs)
41-41: Hard tabs
Column: 1
(MD010, no-hard-tabs)
42-42: Hard tabs
Column: 1
(MD010, no-hard-tabs)
43-43: Hard tabs
Column: 1
(MD010, no-hard-tabs)
44-44: Hard tabs
Column: 1
(MD010, no-hard-tabs)
46-46: Hard tabs
Column: 1
(MD010, no-hard-tabs)
47-47: Hard tabs
Column: 1
(MD010, no-hard-tabs)
48-48: Hard tabs
Column: 1
(MD010, no-hard-tabs)
50-50: Hard tabs
Column: 1
(MD010, no-hard-tabs)
51-51: Hard tabs
Column: 1
(MD010, no-hard-tabs)
52-52: Hard tabs
Column: 1
(MD010, no-hard-tabs)
54-54: Hard tabs
Column: 1
(MD010, no-hard-tabs)
55-55: Hard tabs
Column: 1
(MD010, no-hard-tabs)
57-57: Hard tabs
Column: 1
(MD010, no-hard-tabs)
58-58: Hard tabs
Column: 1
(MD010, no-hard-tabs)
60-60: Hard tabs
Column: 1
(MD010, no-hard-tabs)
61-61: Hard tabs
Column: 1
(MD010, no-hard-tabs)
62-62: Hard tabs
Column: 1
(MD010, no-hard-tabs)
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
🔇 Additional comments (9)
storage.go (5)
3-6: LGTM: Clean context package integration.The addition of the context import is necessary and properly placed to support the new context-aware methods.
11-13: LGTM: Well-designed context-aware getter method.The
GetWithContextmethod signature follows Go conventions with context as the first parameter and maintains consistency with the originalGetmethod.
19-21: LGTM: Consistent context-aware setter design.The
SetWithContextmethod properly extends the originalSetmethod with context support while maintaining the same parameter order and types.
28-30: LGTM: Context-aware delete method implementation.The
DeleteWithContextmethod follows the established pattern and correctly documents the no-error behavior for non-existent keys.
36-37: LGTM: Context-aware reset method completes the interface.The
ResetWithContextmethod rounds out the context-aware interface additions with proper documentation and signature.README.md (4)
29-31: LGTM: Documentation accurately reflects the new GetWithContext method.The interface documentation correctly matches the implementation in storage.go with proper parameter types and return values.
37-39: LGTM: SetWithContext documentation is consistent and accurate.The method documentation properly describes the context-aware version while maintaining consistency with the original method description.
46-48: LGTM: DeleteWithContext documentation maintains interface contract.The documentation correctly preserves the no-error behavior specification for non-existent keys while adding context support.
54-55: LGTM: ResetWithContext documentation completes the context-aware interface.The documentation accurately describes the context-aware reset functionality with clear and concise wording.
This comment was marked as outdated.
This comment was marked as outdated.
There was a problem hiding this comment.
Actionable comments posted: 2
🔭 Outside diff range comments (6)
ristretto/README.md (1)
70-92:DefaultCostfield documented but missing inConfigstruct
ConfigDefaultsets aDefaultCostvalue, yet theConfigstruct above does not define this field.
This mismatch will confuse users and cause compile errors when they try to supplyDefaultCostin a custom config.type Config struct { // NumCounters number of keys to track frequency of (10M). NumCounters int64 @@ // BufferItems number of keys per Get buffer. BufferItems int64 + + // DefaultCost cost assigned when none is provided in Set operations. + DefaultCost int64 }If
DefaultCostis intentionally unused in Ristretto, remove the field fromConfigDefaultinstead.cassandra/README.md (1)
68-75: Constructor example won’t compile – needs package qualifier
Newis declared in packagecassandra, therefore the example should readcassandra.New(…), otherwise it will not build.-// Initialize default config … -store := New(Config{ +// Initialize default config … +store := cassandra.New(cassandra.Config{Also ensure you add the trailing comma after the last field inside the composite literal.
mssql/README.md (1)
68-72: Missing comma breaks the config literalThe
ConnectionURIfield lacks a trailing comma, so the example will not compile.- ConnectionURI: "sqlserver://user:password@localhost:1433?database=fiber" + ConnectionURI: "sqlserver://user:password@localhost:1433?database=fiber",Run
go veton the docs examples to catch these quickly.s3/README.md (1)
79-83: Example call doesn’t match the updatedSetsignature
Set(andSetWithContext) accept anexp time.Durationargument, but the example passes only two parameters:err := store.Set("my-key", []byte("my-value"))This will not compile. Either add an expiration argument, e.g.:
-err := store.Set("my-key", []byte("my-value")) +err := store.Set("my-key", []byte("my-value"), 0) // 0 = no TTLor update the earlier signature block if the driver really supports a 2-arg form.
memcache/README.md (1)
39-46: Installation instructions reference the wrong module (memoryinstead ofmemcache)Copy-pasting the current command installs the in-memory driver, not Memcache.
-go get github.com/gofiber/storage/memory/v2 +go get github.com/gofiber/storage/memcache/v2Please also adjust the preceding paragraph (“Memory is tested …”) to “Memcache is tested …”.
leveldb/leveldb.go (1)
102-108: Missing DeleteWithContext method implementation.The
Deletemethod exists but there's no correspondingDeleteWithContextmethod, even though it's documented in the README. This creates an inconsistency in the context-aware interface implementation.Add the missing
DeleteWithContextmethod:+// DeleteWithContext deletes key by key (dummy context support) +func (s *Storage) DeleteWithContext(ctx context.Context, key string) error { + return s.Delete(key) +}
♻️ Duplicate comments (4)
azureblob/README.md (1)
27-34: Same documentation hint as MySQL READMEApply the same brief explanation of the new
*WithContextmethods here for consistency across drivers.redis/README.md (1)
28-35: Match explanation of*WithContextmethodsReplicate the short contextual-usage note suggested in the MySQL README so Redis users get the same guidance.
dynamodb/README.md (1)
30-36: Add quick note about context purposeEchoing the earlier comment: include a one-liner describing why the
*WithContextforms exist (deadlines, cancellation) to keep the README self-contained.postgres/README.md (1)
27-33: Briefly explain the context-aware signaturesFor parity with other drivers, insert a concise explanation that
*WithContextenables deadline / cancellation propagation and that traditional methods wrap them withcontext.Background().
🧹 Nitpick comments (29)
neo4j/README.md (1)
26-32: Brief explanation of the new context-aware methods is missingThe signature list now contains the four
*WithContextvariants, but there is no accompanying sentence that explains why they exist or how they relate to their non-context counterparts. A short note (one line before or after the code block) stating that the plain methods delegate to the*WithContextversions usingcontext.Background()would make the addition immediately clear to readers skimming the doc.-```go +// Every plain method is a thin wrapper around its context-aware +// counterpart and passes context.Background() internally. +```gobadger/README.md (2)
27-33: Add explicit imports in the signature block for copy-paste readinessThe new
WithContextsignatures refer tocontext.Contextandtime.Duration, but the snippet doesn’t show the necessary imports. Adding them makes the block self-contained and prevents copy-paste compilation errors.func New(config ...Config) Storage -import ( - "context" - "time" -) func (s *Storage) Get(key string) ([]byte, error) func (s *Storage) GetWithContext(ctx context.Context, key string) ([]byte, error) ...
38-39: Rephrase “dummy methods” to avoid confusionCalling the new functions “dummy methods” could be misinterpreted as placeholders that are not implemented. Consider wording that conveys they intentionally ignore the context because Badger’s API is not context-aware, while still being fully functional.
-**Note:** The context methods are dummy methods and don't have any functionality, as Badger does not support context cancellation in its client library. +**Note:** These context variants currently ignore the supplied `context.Context` because the Badger client is not context-aware. They exist solely to satisfy the Fiber `Storage` interface and behave identically to their non-context counterparts.valkey/README.md (1)
24-31: ClarifyWithContextvariants and add import noteReaders who copy-paste these signatures will need to import the
contextpackage explicitly (same fortime). Consider adding a short remark right below the code block, e.g. “Remember toimport "context"”, or include the imports in a complete snippet to avoid copy-paste surprises.etcd/README.md (1)
23-34: Provide a usage snippet for the new*WithContextAPIsThe new context-aware signatures are documented, but there’s no accompanying example that shows how to create / cancel a
context.Contextand pass it toGetWithContext,SetWithContext, etc. A concise snippet in the Examples section (e.g. usingctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)) would help readers adopt the new methods instead of falling back to the wrappers without context.sqlite3/README.md (1)
25-31: Addcontext&timeimports to the signature snippet for completenessThe updated signatures reference both
context.Contextandtime.Duration, yet the snippet omits the corresponding imports. Adding them avoids confusion for newcomers who copy-paste this block verbatim.func New(config ...Config) Storage +// required imports +import ( + "context" + "time" +) func (s *Storage) Get(key string) ([]byte, error) func (s *Storage) GetWithContext(ctx context.Context, key string) ([]byte, error) func (s *Storage) Set(key string, val []byte, exp time.Duration) error func (s *Storage) SetWithContext(ctx context.Context, key string, val []byte, exp time.Duration) error func (s *Storage) Delete(key string) error func (s *Storage) DeleteWithContext(ctx context.Context, key string) error func (s *Storage) Reset() error func (s *Storage) ResetWithContext(ctx context.Context) errorbbolt/README.md (2)
22-34: Add missingimportlines for compile-ready snippetThe signature block references
context.Contextandtime.Duration, but the example omits the corresponding imports. Readers copying the snippet will hit “undefined” compiler errors. Consider prefixing the block with:import ( "context" "time" )(or add a short comment that those packages are required).
35-37: Re-phrase the “dummy methods” disclaimerCalling the functions dummy may be mis-read as “no-op”. They actually invoke the non-context versions and therefore still perform the storage action, just without honoring cancellation. Suggest something along these lines for clarity:
**Note:** These methods forward to their non-context counterparts because the underlying Bbolt API lacks context-aware primitives. They exist solely to satisfy the updated `fiber.Storage` interface; context cancellation is **not** enforced.couchbase/README.md (1)
24-32: Add thecontextimport (or a short note) for copy-paste friendlinessThe signatures block now references
context.Context, but readers who copy the snippet verbatim will hitundefined: context.
Either include:import "context"at the top of the snippet or add a one-liner beneath the code block clarifying that
contextmust be imported.memory/README.md (2)
27-34: Document required imports for the new signaturesThe examples list the new
*WithContextmethods but the README never shows that callers must import thecontextpackage (e.g.import "context"). A quick one-liner in either the “Signatures” or first code example would prevent the inevitable “undefined: context” confusion.func New(config ...Config) Storage func (s *Storage) Get(key string) ([]byte, error) +// ctx must be a standard context from `import "context"` func (s *Storage) GetWithContext(ctx context.Context, key string) ([]byte, error)
39-40: Clarify the behaviour of the dummy context methodsThe note correctly states that the memory driver ignores cancellation, but readers could misinterpret this as “context is entirely useless”. A short clarification that the methods do perform a fast ‑path
if ctx.Err() != nil { return nil, ctx.Err() }(if that’s the case), or explicitly that they never touch the context at all, would set the right expectations and avoid surprises when callers pass already-cancelled contexts.minio/README.md (1)
24-39: Include required imports for a copy-paste-ready snippet
context.Contextandtime.Durationare referenced, but their imports are missing. Adding them makes the example compile out of the box.```go +import ( + "context" + "time" +) + func New(config ...Config) Storage func (s *Storage) Get(key string) ([]byte, error) func (s *Storage) GetWithContext(ctx context.Context, key string) ([]byte, error) ...cloudflarekv/README.md (1)
24-36: Add import statements to prevent copy-paste friction in the Signatures blockThe new
*WithContextsignatures referencecontext.Contextandtime.Duration, but the snippet omits their corresponding imports. Readers who copy this block into an editor will hit “undefined” compilation errors. Consider expanding the snippet to include:import ( "context" "time" )clickhouse/README.md (1)
22-28: Add missing import hints forcontextandtimein the snippetThe newly added
*WithContextmethods referencecontext.Contextandtime.Duration, but the snippet lacks an import block. Readers copying this code verbatim will hit a compilation error.func New(config ...Config) (*Storage, error) +// Required imports for the signatures below: +// import ( +// "context" +// "time" +// ) func (s *Storage) Get(key string) ([]byte, error) func (s *Storage) GetWithContext(ctx context.Context, key string) ([]byte, error) func (s *Storage) Set(key string, val []byte, exp time.Duration) error func (s *Storage) SetWithContext(ctx context.Context, key string, val []byte, exp time.Duration) error func (s *Storage) Delete(key string) error func (s *Storage) DeleteWithContext(ctx context.Context, key string) error func (s *Storage) Reset() error func (s *Storage) ResetWithContext(ctx context.Context) errorEven a short comment block (as above) is enough to prevent confusion.
ristretto/README.md (2)
28-35: Add missing import statements to the code snippet for compilabilityThe signature block now references
context.Contextandtime.Duration, but the surrounding snippet does not include animportsection. Copy-pasting the snippet as-is will not compile.
Consider expanding the snippet to show the required imports:func New(config ...Config) Storage +// Required imports +import ( + "context" + "time" +) func (s *Storage) Get(key string) ([]byte, error) func (s *Storage) GetWithContext(ctx context.Context, key string) ([]byte, error) ...
39-39: Clarify the “dummy methods” disclaimerThe current wording could be misread as the methods doing nothing at all, which might alarm users.
Recommend clarifying that they ignorectx.Done()but still execute the underlying operation:-**Note:** The context methods are dummy methods and don't have any functionality, as Ristretto does not support context cancellation in its client library. +**Note:** These context-aware wrappers execute the same logic as their non-context variants; they simply ignore `ctx.Done()` because Ristretto’s client API has no cancellation support. They exist solely to satisfy the Fiber `Storage` interface.surrealdb/README.md (2)
23-29: Consider adding thecontextimport for completenessThe signature block now references
context.Context, but the snippet does not show the import statement. Readers who copy-paste the example will have to add it manually. A one-liner keeps the doc self-contained:+import "context" // 👈 add this before the signatures
35-36: Clarify that “dummy” means “delegates to non-context methods”The note hints that the new methods are no-ops, which might worry readers about lost cancellation semantics. Explicitly stating that they internally call the original methods with
context.Background()would remove the ambiguity and align with the pattern used in other drivers.aerospike/README.md (1)
39-40: Wording nit – prefer “context-aware” and explicitly say the ctx is ignoredTiny style tweak to improve clarity and align with terminology used elsewhere in the repo.
-**Note:** The context methods are dummy methods and don't have any functionality, as Aerospike does not support context cancellation in its client library. They are provided for compliance with the Fiber storage interface. +**Note:** The context-aware methods are no-ops (`ctx` is ignored) because the official Aerospike Go client does not expose context cancellation. They exist solely to satisfy the Fiber storage interface.pebble/README.md (1)
38-38: Re-phrase the “dummy methods” disclaimerStating that the context wrappers “don’t have any functionality” may discourage users from calling them.
Consider clarifying that the methods currently ignore cancellation but exist to satisfy thefiber.Storageinterface, and that future versions may add best-effort checks (e.g.select { case <-ctx.Done(): … }) even without native Pebble support.
This keeps the door open for improvements while setting correct expectations.mysql/README.md (1)
26-33: Clarify “WithContext” variants in the READMENice to see the context-aware methods listed, but a short note explaining why/when to prefer the
*WithContextvariants (cancellation, timeouts, deadlines) would help users quickly understand the new API surface. One sentence right above the signature block would be enough.Example:
-### Signatures +### Signatures +All `*WithContext` methods accept a `context.Context`, allowing callers to propagate +cancellation and deadlines; the legacy helpers delegate to them with +`context.Background()` for backward-compatibility.cassandra/README.md (1)
22-28: Add missingcontextandtimeimports to signature block for self-containmentThe signature list references
context.Contextandtime.Durationbut the snippet omits the corresponding imports, which can confuse copy-and-paste users.-func (s *Storage) GetWithContext(ctx context.Context, key string) ([]byte, error) +// import "context" +func (s *Storage) GetWithContext(ctx context.Context, key string) ([]byte, error)Same for
time.Duration.mongodb/README.md (2)
25-31: Consistency: include imports in signature blockFor parity with the other READMEs, consider adding a small preamble or comment that
contextandtimeare required imports so readers can copy the block verbatim.
66-71: Mis-aligned indentation & stray tabs in exampleThe example config literal mixes tabs and spaces (
Database: "fiber"etc.). This renders oddly in Markdown and breaksgo fmtwhen copied.- Database: "fiber", - Collection: "fiber_storage", - Reset: false, + Database: "fiber", + Collection: "fiber_storage", + Reset: false,mssql/README.md (1)
25-31: Import hints forcontext/timeSame remark as other drivers: explicitly mention the imports so the snippet is self-contained.
s3/README.md (1)
24-36: Add missingcontextimport in signature snippet
The new*WithContextmethods referencecontext.Context, but the snippet does not show the required import. Readers copy-pasting this block will hit an “undefined: context” compile error.func New(config ...Config) Storage +// remember to import "context" func (s *Storage) Get(key string) ([]byte, error)Including the import (or a comment reminding readers) keeps the example copy-pastable.
memcache/README.md (3)
25-31:context.Contextimport hint is missingThe newly added context-aware signatures reference
context.Context, yet the snippet omits animportblock.
Readers unfamiliar with Go may try copy-pasting and hit a compile error.Add a short import stanza or a comment, e.g.:
// import "context"
36-36: Clarify “dummy methods” wordingStating that the methods are “dummy” could imply they are stubs and unsafe to call.
Consider rephrasing to emphasise they are thin wrappers delegating to the original methods for interface compliance.Example:
-**Note:** The context methods are dummy methods and don't have any functionality... +**Note:** These context-aware methods internally delegate to their non-context counterparts. +They exist solely to satisfy the Fiber storage interface because the underlying Memcache +client does not support context cancellation.
83-86:ConfigDefaultomits theResetfieldThe public struct exposes
Reset, but the default value struct doesn’t set it.
Either include it withfalse(explicit) or explain why it is intentionally omitted.var ConfigDefault = Config{ Servers: "127.0.0.1:11211", + Reset: false, }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
.github/workflows/benchmark.ymlis excluded by!**/*.yml
📒 Files selected for processing (32)
aerospike/README.md(1 hunks)azureblob/README.md(1 hunks)badger/README.md(1 hunks)bbolt/README.md(1 hunks)cassandra/README.md(1 hunks)clickhouse/README.md(1 hunks)cloudflarekv/README.md(1 hunks)coherence/README.md(1 hunks)couchbase/README.md(1 hunks)dynamodb/README.md(1 hunks)etcd/README.md(1 hunks)leveldb/README.md(1 hunks)leveldb/leveldb.go(5 hunks)leveldb/leveldb_test.go(11 hunks)memcache/README.md(1 hunks)memory/README.md(1 hunks)minio/README.md(1 hunks)mongodb/README.md(1 hunks)mssql/README.md(1 hunks)mysql/README.md(1 hunks)nats/README.md(1 hunks)neo4j/README.md(1 hunks)pebble/README.md(1 hunks)postgres/README.md(1 hunks)redis/README.md(1 hunks)ristretto/README.md(2 hunks)rueidis/README.md(1 hunks)s3/README.md(1 hunks)scylladb/README.md(1 hunks)sqlite3/README.md(1 hunks)surrealdb/README.md(1 hunks)valkey/README.md(1 hunks)
✅ Files skipped from review due to trivial changes (4)
- leveldb/leveldb_test.go
- rueidis/README.md
- nats/README.md
- scylladb/README.md
🧰 Additional context used
🧠 Learnings (29)
📓 Common learnings
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/cache/cache_test.go:897-897
Timestamp: 2024-11-08T04:10:42.990Z
Learning: In the Fiber framework, `Context()` is being renamed to `RequestCtx()`, and `UserContext()` to `Context()` to improve clarity and align with Go's context conventions.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: itssimon
PR: gofiber/recipes#3108
File: monitoring-with-apitally/main.go:90-105
Timestamp: 2025-05-14T01:04:10.042Z
Learning: In recipe examples for the gofiber/recipes repository, it's acceptable to have placeholder comments for business logic (like data storage) when the primary focus is on demonstrating a specific integration or feature (such as Apitally monitoring).
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/adaptor/adaptor.go:111-111
Timestamp: 2024-11-10T23:44:13.704Z
Learning: In the `middleware/adaptor/adaptor.go` file of the Fiber framework, when updating context handling, replacing `c.Context()` with `c.RequestCtx()` is appropriate to access the `fasthttp.RequestCtx`.
Learnt from: ReneWerner87
PR: gofiber/contrib#0
File: :0-0
Timestamp: 2024-11-29T15:24:06.083Z
Learning: When customizing the Fiber context to achieve version independence, using generics in methods like `Status` and `Type` allows for fluent method chaining. Implementing a generic interface for `Ctx` on the `App` prevents class switching when registering custom contexts that use fluent methods. Providing multiple `New` methods allows users who do not wish to customize the context to continue using `fiber.New` without changes.
Learnt from: the-real-i9
PR: gofiber/storage#1562
File: neo4j/neo4j.go:50-52
Timestamp: 2025-01-30T12:29:41.774Z
Learning: Storage drivers in the gofiber/storage repository intentionally panic on connection errors as a design choice to fail fast when storage is unavailable.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/server/server.go:14-16
Timestamp: 2024-11-23T19:50:41.765Z
Learning: In the `clean-code` example at `clean-code/app/server/server.go` using the Go Fiber framework, it's acceptable to omit production-level features like context usage and graceful shutdown handling to keep the example simple.
Learnt from: efectn
PR: gofiber/fiber#3162
File: app_test.go:893-895
Timestamp: 2024-11-29T12:37:27.581Z
Learning: In the `Test_App_ShutdownWithContext` function in `app_test.go`, the `clientDone` channel is used to synchronize the client's request completion before proceeding, eliminating the need for additional `time.Sleep` calls.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/db_mock.go:13-19
Timestamp: 2024-11-23T19:50:06.387Z
Learning: In test code within `clean-code/app/datasources/database/db_mock.go`, adding safety checks like context validation, safe type assertions, and extra documentation is not necessary.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:106-107
Timestamp: 2024-07-01T15:49:51.308Z
Learning: The `IsZero` function for `time.Time` structs in the ClickHouse storage driver was returning false even for zero value `time.Time` structs. As a result, a different verification logic was implemented to avoid bugs.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:106-107
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The `IsZero` function for `time.Time` structs in the ClickHouse storage driver was returning false even for zero value `time.Time` structs. As a result, a different verification logic was implemented to avoid bugs.
memory/README.md (13)
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/memory_db.go:0-0
Timestamp: 2024-11-25T19:31:39.216Z
Learning: The `memoryDB` implementation in `clean-code/app/datasources/database/memory_db.go` is not intended for production use, so input validation, concurrency protection, and context usage are not required in this file.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/memory_db.go:13-16
Timestamp: 2024-11-25T19:31:53.726Z
Learning: The `memoryDB` implementation in `clean-code/app/datasources/database/memory_db.go` is not intended for production use, so adding concurrency protection is not necessary.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/memory_db_test.go:0-0
Timestamp: 2024-11-25T19:36:45.661Z
Learning: In the `clean-code/app/datasources/database/memory_db.go`, the in-memory database implementation is not intended for production use. Therefore, adding extensive tests for concurrency and error handling in `memory_db_test.go` is unnecessary.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/memory_db.go:18-20
Timestamp: 2024-11-25T19:31:36.658Z
Learning: In `clean-code/app/datasources/database/memory_db.go`, the `memoryDB` implementation is intended as an example and not for production use.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/cache/cache_test.go:897-897
Timestamp: 2024-11-08T04:10:42.990Z
Learning: In the Fiber framework, `Context()` is being renamed to `RequestCtx()`, and `UserContext()` to `Context()` to improve clarity and align with Go's context conventions.
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: the-real-i9
PR: gofiber/storage#1562
File: neo4j/neo4j.go:50-52
Timestamp: 2025-01-30T12:29:41.774Z
Learning: Storage drivers in the gofiber/storage repository intentionally panic on connection errors as a design choice to fail fast when storage is unavailable.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-07-26T21:00:12.902Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
azureblob/README.md (3)
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
aerospike/README.md (15)
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/cache/cache_test.go:897-897
Timestamp: 2024-11-08T04:10:42.990Z
Learning: In the Fiber framework, `Context()` is being renamed to `RequestCtx()`, and `UserContext()` to `Context()` to improve clarity and align with Go's context conventions.
Learnt from: the-real-i9
PR: gofiber/storage#1562
File: neo4j/neo4j.go:50-52
Timestamp: 2025-01-30T12:29:41.774Z
Learning: Storage drivers in the gofiber/storage repository intentionally panic on connection errors as a design choice to fail fast when storage is unavailable.
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/adaptor/adaptor.go:111-111
Timestamp: 2024-11-10T23:44:13.704Z
Learning: In the `middleware/adaptor/adaptor.go` file of the Fiber framework, when updating context handling, replacing `c.Context()` with `c.RequestCtx()` is appropriate to access the `fasthttp.RequestCtx`.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/server/server.go:14-16
Timestamp: 2024-11-23T19:50:41.765Z
Learning: In the `clean-code` example at `clean-code/app/server/server.go` using the Go Fiber framework, it's acceptable to omit production-level features like context usage and graceful shutdown handling to keep the example simple.
Learnt from: mdelapenya
PR: gofiber/fiber#3434
File: docs/api/services.md:39-43
Timestamp: 2025-05-07T13:07:33.899Z
Learning: When documenting Go interface methods in the Fiber project, avoid showing method signatures with the interface type as the receiver (e.g., `func (d *Service) Method()`) since interfaces cannot be used as receivers in Go. Instead, show just the method signature without a receiver or use a placeholder implementation name.
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
Learnt from: ReneWerner87
PR: gofiber/fiber#3161
File: app.go:923-932
Timestamp: 2024-11-15T07:56:21.623Z
Learning: In the Fiber framework, breaking changes are acceptable when moving from version 2 to version 3, including modifications to method signatures such as in the `Test` method in `app.go`.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-07-26T21:00:12.902Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:114-115
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, MongoDB, and Clickhouse.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:114-115
Timestamp: 2024-07-01T15:47:48.701Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, MongoDB, and Clickhouse.
badger/README.md (13)
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/cache/cache_test.go:897-897
Timestamp: 2024-11-08T04:10:42.990Z
Learning: In the Fiber framework, `Context()` is being renamed to `RequestCtx()`, and `UserContext()` to `Context()` to improve clarity and align with Go's context conventions.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/db_mock.go:13-19
Timestamp: 2024-11-23T19:50:06.387Z
Learning: In test code within `clean-code/app/datasources/database/db_mock.go`, adding safety checks like context validation, safe type assertions, and extra documentation is not necessary.
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/adaptor/adaptor.go:111-111
Timestamp: 2024-11-10T23:44:13.704Z
Learning: In the `middleware/adaptor/adaptor.go` file of the Fiber framework, when updating context handling, replacing `c.Context()` with `c.RequestCtx()` is appropriate to access the `fasthttp.RequestCtx`.
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: the-real-i9
PR: gofiber/storage#1562
File: neo4j/neo4j.go:50-52
Timestamp: 2025-01-30T12:29:41.774Z
Learning: Storage drivers in the gofiber/storage repository intentionally panic on connection errors as a design choice to fail fast when storage is unavailable.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-07-26T21:00:12.902Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:114-115
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, MongoDB, and Clickhouse.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:114-115
Timestamp: 2024-07-01T15:47:48.701Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, MongoDB, and Clickhouse.
redis/README.md (6)
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/cache/cache_test.go:897-897
Timestamp: 2024-11-08T04:10:42.990Z
Learning: In the Fiber framework, `Context()` is being renamed to `RequestCtx()`, and `UserContext()` to `Context()` to improve clarity and align with Go's context conventions.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-07-26T21:00:12.902Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:114-115
Timestamp: 2024-07-01T15:47:48.701Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, MongoDB, and Clickhouse.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:114-115
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, MongoDB, and Clickhouse.
coherence/README.md (4)
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/cache/cache_test.go:897-897
Timestamp: 2024-11-08T04:10:42.990Z
Learning: In the Fiber framework, `Context()` is being renamed to `RequestCtx()`, and `UserContext()` to `Context()` to improve clarity and align with Go's context conventions.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
leveldb/README.md (16)
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/cache/cache_test.go:897-897
Timestamp: 2024-11-08T04:10:42.990Z
Learning: In the Fiber framework, `Context()` is being renamed to `RequestCtx()`, and `UserContext()` to `Context()` to improve clarity and align with Go's context conventions.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/db_mock.go:13-19
Timestamp: 2024-11-23T19:50:06.387Z
Learning: In test code within `clean-code/app/datasources/database/db_mock.go`, adding safety checks like context validation, safe type assertions, and extra documentation is not necessary.
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/adaptor/adaptor.go:111-111
Timestamp: 2024-11-10T23:44:13.704Z
Learning: In the `middleware/adaptor/adaptor.go` file of the Fiber framework, when updating context handling, replacing `c.Context()` with `c.RequestCtx()` is appropriate to access the `fasthttp.RequestCtx`.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/memory_db.go:0-0
Timestamp: 2024-11-25T19:31:39.216Z
Learning: The `memoryDB` implementation in `clean-code/app/datasources/database/memory_db.go` is not intended for production use, so input validation, concurrency protection, and context usage are not required in this file.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/server/server.go:14-16
Timestamp: 2024-11-23T19:50:41.765Z
Learning: In the `clean-code` example at `clean-code/app/server/server.go` using the Go Fiber framework, it's acceptable to omit production-level features like context usage and graceful shutdown handling to keep the example simple.
Learnt from: ReneWerner87
PR: gofiber/contrib#0
File: :0-0
Timestamp: 2024-11-29T15:24:06.083Z
Learning: When customizing the Fiber context to achieve version independence, using generics in methods like `Status` and `Type` allows for fluent method chaining. Implementing a generic interface for `Ctx` on the `App` prevents class switching when registering custom contexts that use fluent methods. Providing multiple `New` methods allows users who do not wish to customize the context to continue using `fiber.New` without changes.
Learnt from: the-real-i9
PR: gofiber/storage#1562
File: neo4j/neo4j.go:50-52
Timestamp: 2025-01-30T12:29:41.774Z
Learning: Storage drivers in the gofiber/storage repository intentionally panic on connection errors as a design choice to fail fast when storage is unavailable.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-07-26T21:00:12.902Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:114-115
Timestamp: 2024-07-01T15:47:48.701Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, MongoDB, and Clickhouse.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:114-115
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, MongoDB, and Clickhouse.
neo4j/README.md (10)
Learnt from: the-real-i9
PR: gofiber/storage#1562
File: neo4j/neo4j.go:44-45
Timestamp: 2025-01-30T12:32:54.196Z
Learning: In the Neo4j storage driver, connection errors are handled by panicking during connectivity verification, making additional error logging redundant.
Learnt from: the-real-i9
PR: gofiber/storage#1562
File: neo4j/neo4j.go:44-45
Timestamp: 2025-01-30T12:32:54.196Z
Learning: In the Neo4j storage driver, connection errors are handled through `VerifyConnectivity` which panics on failure, making additional error logging at connection creation time redundant.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-07-26T21:00:12.902Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: the-real-i9
PR: gofiber/storage#1562
File: neo4j/neo4j.go:50-52
Timestamp: 2025-01-30T12:29:41.774Z
Learning: In the Neo4j storage driver initialization, connectivity verification errors are considered unexpected according to the maintainer.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
surrealdb/README.md (13)
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/cache/cache_test.go:897-897
Timestamp: 2024-11-08T04:10:42.990Z
Learning: In the Fiber framework, `Context()` is being renamed to `RequestCtx()`, and `UserContext()` to `Context()` to improve clarity and align with Go's context conventions.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/db_mock.go:13-19
Timestamp: 2024-11-23T19:50:06.387Z
Learning: In test code within `clean-code/app/datasources/database/db_mock.go`, adding safety checks like context validation, safe type assertions, and extra documentation is not necessary.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/memory_db.go:0-0
Timestamp: 2024-11-25T19:31:39.216Z
Learning: The `memoryDB` implementation in `clean-code/app/datasources/database/memory_db.go` is not intended for production use, so input validation, concurrency protection, and context usage are not required in this file.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-07-26T21:00:12.902Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: the-real-i9
PR: gofiber/storage#1562
File: neo4j/neo4j.go:50-52
Timestamp: 2025-01-30T12:29:41.774Z
Learning: Storage drivers in the gofiber/storage repository intentionally panic on connection errors as a design choice to fail fast when storage is unavailable.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:114-115
Timestamp: 2024-07-01T15:47:48.701Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, MongoDB, and Clickhouse.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:114-115
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, MongoDB, and Clickhouse.
mysql/README.md (8)
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/db_mock.go:13-19
Timestamp: 2024-11-23T19:50:06.387Z
Learning: In test code within `clean-code/app/datasources/database/db_mock.go`, adding safety checks like context validation, safe type assertions, and extra documentation is not necessary.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/memory_db.go:0-0
Timestamp: 2024-11-25T19:31:39.216Z
Learning: The `memoryDB` implementation in `clean-code/app/datasources/database/memory_db.go` is not intended for production use, so input validation, concurrency protection, and context usage are not required in this file.
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: the-real-i9
PR: gofiber/storage#1562
File: neo4j/neo4j.go:50-52
Timestamp: 2025-01-30T12:29:41.774Z
Learning: Storage drivers in the gofiber/storage repository intentionally panic on connection errors as a design choice to fail fast when storage is unavailable.
cassandra/README.md (6)
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/db_mock.go:13-19
Timestamp: 2024-11-23T19:50:06.387Z
Learning: In test code within `clean-code/app/datasources/database/db_mock.go`, adding safety checks like context validation, safe type assertions, and extra documentation is not necessary.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
s3/README.md (3)
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
valkey/README.md (3)
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
postgres/README.md (5)
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/db_mock.go:13-19
Timestamp: 2024-11-23T19:50:06.387Z
Learning: In test code within `clean-code/app/datasources/database/db_mock.go`, adding safety checks like context validation, safe type assertions, and extra documentation is not necessary.
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
Learnt from: the-real-i9
PR: gofiber/storage#1562
File: neo4j/neo4j.go:50-52
Timestamp: 2025-01-30T12:29:41.774Z
Learning: Storage drivers in the gofiber/storage repository intentionally panic on connection errors as a design choice to fail fast when storage is unavailable.
memcache/README.md (7)
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/memory_db.go:0-0
Timestamp: 2024-11-25T19:31:39.216Z
Learning: The `memoryDB` implementation in `clean-code/app/datasources/database/memory_db.go` is not intended for production use, so input validation, concurrency protection, and context usage are not required in this file.
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: the-real-i9
PR: gofiber/storage#1562
File: neo4j/neo4j.go:50-52
Timestamp: 2025-01-30T12:29:41.774Z
Learning: Storage drivers in the gofiber/storage repository intentionally panic on connection errors as a design choice to fail fast when storage is unavailable.
pebble/README.md (11)
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/cache/cache_test.go:897-897
Timestamp: 2024-11-08T04:10:42.990Z
Learning: In the Fiber framework, `Context()` is being renamed to `RequestCtx()`, and `UserContext()` to `Context()` to improve clarity and align with Go's context conventions.
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-07-26T21:00:12.902Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: the-real-i9
PR: gofiber/storage#1562
File: neo4j/neo4j.go:50-52
Timestamp: 2025-01-30T12:29:41.774Z
Learning: Storage drivers in the gofiber/storage repository intentionally panic on connection errors as a design choice to fail fast when storage is unavailable.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:114-115
Timestamp: 2024-07-01T15:47:48.701Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, MongoDB, and Clickhouse.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:114-115
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, MongoDB, and Clickhouse.
dynamodb/README.md (3)
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-07-26T21:00:12.902Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
clickhouse/README.md (13)
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:106-107
Timestamp: 2024-07-01T15:49:51.308Z
Learning: The `IsZero` function for `time.Time` structs in the ClickHouse storage driver was returning false even for zero value `time.Time` structs. As a result, a different verification logic was implemented to avoid bugs.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:106-107
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The `IsZero` function for `time.Time` structs in the ClickHouse storage driver was returning false even for zero value `time.Time` structs. As a result, a different verification logic was implemented to avoid bugs.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/db_mock.go:13-19
Timestamp: 2024-11-23T19:50:06.387Z
Learning: In test code within `clean-code/app/datasources/database/db_mock.go`, adding safety checks like context validation, safe type assertions, and extra documentation is not necessary.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse_test.go:138-160
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The `Test_Reset` function in `clickhouse/clickhouse_test.go` already includes a verification step to ensure the storage is empty after a reset operation by checking that a previously set key returns an empty byte slice.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse_test.go:138-160
Timestamp: 2024-07-01T15:48:53.094Z
Learning: The `Test_Reset` function in `clickhouse/clickhouse_test.go` already includes a verification step to ensure the storage is empty after a reset operation by checking that a previously set key returns an empty byte slice.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/memory_db.go:0-0
Timestamp: 2024-11-25T19:31:39.216Z
Learning: The `memoryDB` implementation in `clean-code/app/datasources/database/memory_db.go` is not intended for production use, so input validation, concurrency protection, and context usage are not required in this file.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:114-115
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, MongoDB, and Clickhouse.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:114-115
Timestamp: 2024-07-01T15:47:48.701Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, MongoDB, and Clickhouse.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
cloudflarekv/README.md (4)
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/cache/cache_test.go:897-897
Timestamp: 2024-11-08T04:10:42.990Z
Learning: In the Fiber framework, `Context()` is being renamed to `RequestCtx()`, and `UserContext()` to `Context()` to improve clarity and align with Go's context conventions.
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
bbolt/README.md (13)
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/cache/cache_test.go:897-897
Timestamp: 2024-11-08T04:10:42.990Z
Learning: In the Fiber framework, `Context()` is being renamed to `RequestCtx()`, and `UserContext()` to `Context()` to improve clarity and align with Go's context conventions.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/adaptor/adaptor.go:111-111
Timestamp: 2024-11-10T23:44:13.704Z
Learning: In the `middleware/adaptor/adaptor.go` file of the Fiber framework, when updating context handling, replacing `c.Context()` with `c.RequestCtx()` is appropriate to access the `fasthttp.RequestCtx`.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/db_mock.go:13-19
Timestamp: 2024-11-23T19:50:06.387Z
Learning: In test code within `clean-code/app/datasources/database/db_mock.go`, adding safety checks like context validation, safe type assertions, and extra documentation is not necessary.
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: the-real-i9
PR: gofiber/storage#1562
File: neo4j/neo4j.go:50-52
Timestamp: 2025-01-30T12:29:41.774Z
Learning: Storage drivers in the gofiber/storage repository intentionally panic on connection errors as a design choice to fail fast when storage is unavailable.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-07-26T21:00:12.902Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:114-115
Timestamp: 2024-07-01T15:47:48.701Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, MongoDB, and Clickhouse.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:114-115
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, MongoDB, and Clickhouse.
couchbase/README.md (8)
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/cache/cache_test.go:897-897
Timestamp: 2024-11-08T04:10:42.990Z
Learning: In the Fiber framework, `Context()` is being renamed to `RequestCtx()`, and `UserContext()` to `Context()` to improve clarity and align with Go's context conventions.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/db_mock.go:13-19
Timestamp: 2024-11-23T19:50:06.387Z
Learning: In test code within `clean-code/app/datasources/database/db_mock.go`, adding safety checks like context validation, safe type assertions, and extra documentation is not necessary.
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/adaptor/adaptor.go:111-111
Timestamp: 2024-11-10T23:44:13.704Z
Learning: In the `middleware/adaptor/adaptor.go` file of the Fiber framework, when updating context handling, replacing `c.Context()` with `c.RequestCtx()` is appropriate to access the `fasthttp.RequestCtx`.
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
mssql/README.md (4)
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/db_mock.go:13-19
Timestamp: 2024-11-23T19:50:06.387Z
Learning: In test code within `clean-code/app/datasources/database/db_mock.go`, adding safety checks like context validation, safe type assertions, and extra documentation is not necessary.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
etcd/README.md (3)
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
mongodb/README.md (8)
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/db_mock.go:13-19
Timestamp: 2024-11-23T19:50:06.387Z
Learning: In test code within `clean-code/app/datasources/database/db_mock.go`, adding safety checks like context validation, safe type assertions, and extra documentation is not necessary.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-07-26T21:00:12.902Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
leveldb/leveldb.go (12)
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-07-26T21:00:12.902Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:114-115
Timestamp: 2024-07-01T15:47:48.701Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, MongoDB, and Clickhouse.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:114-115
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, MongoDB, and Clickhouse.
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/cache/cache_test.go:897-897
Timestamp: 2024-11-08T04:10:42.990Z
Learning: In the Fiber framework, `Context()` is being renamed to `RequestCtx()`, and `UserContext()` to `Context()` to improve clarity and align with Go's context conventions.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/memory_db.go:0-0
Timestamp: 2024-11-25T19:31:39.216Z
Learning: The `memoryDB` implementation in `clean-code/app/datasources/database/memory_db.go` is not intended for production use, so input validation, concurrency protection, and context usage are not required in this file.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/db_mock.go:13-19
Timestamp: 2024-11-23T19:50:06.387Z
Learning: In test code within `clean-code/app/datasources/database/db_mock.go`, adding safety checks like context validation, safe type assertions, and extra documentation is not necessary.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/memory_db.go:18-20
Timestamp: 2024-11-25T19:31:36.658Z
Learning: In `clean-code/app/datasources/database/memory_db.go`, the `memoryDB` implementation is intended as an example and not for production use.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:79-80
Timestamp: 2024-07-01T15:49:08.666Z
Learning: Returning an empty byte array for an empty key is the default behavior for `Get` methods across various storage drivers in the repository.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:79-80
Timestamp: 2024-10-08T19:06:06.583Z
Learning: Returning an empty byte array for an empty key is the default behavior for `Get` methods across various storage drivers in the repository.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse_test.go:138-160
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The `Test_Reset` function in `clickhouse/clickhouse_test.go` already includes a verification step to ensure the storage is empty after a reset operation by checking that a previously set key returns an empty byte slice.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse_test.go:138-160
Timestamp: 2024-07-01T15:48:53.094Z
Learning: The `Test_Reset` function in `clickhouse/clickhouse_test.go` already includes a verification step to ensure the storage is empty after a reset operation by checking that a previously set key returns an empty byte slice.
ristretto/README.md (11)
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/cache/cache_test.go:897-897
Timestamp: 2024-11-08T04:10:42.990Z
Learning: In the Fiber framework, `Context()` is being renamed to `RequestCtx()`, and `UserContext()` to `Context()` to improve clarity and align with Go's context conventions.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-07-26T21:00:12.902Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:114-115
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, MongoDB, and Clickhouse.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:114-115
Timestamp: 2024-07-01T15:47:48.701Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, MongoDB, and Clickhouse.
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: the-real-i9
PR: gofiber/storage#1562
File: neo4j/neo4j.go:50-52
Timestamp: 2025-01-30T12:29:41.774Z
Learning: Storage drivers in the gofiber/storage repository intentionally panic on connection errors as a design choice to fail fast when storage is unavailable.
minio/README.md (1)
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
sqlite3/README.md (4)
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/db_mock.go:13-19
Timestamp: 2024-11-23T19:50:06.387Z
Learning: In test code within `clean-code/app/datasources/database/db_mock.go`, adding safety checks like context validation, safe type assertions, and extra documentation is not necessary.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
⏰ Context from checks skipped due to timeout of 90000ms (138)
- GitHub Check: compare (pebble)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x, 7)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x, 8)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: compare (pebble)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x, 7)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x, 8)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: compare (pebble)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x, 7)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x, 8)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: compare (pebble)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x, 7)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x, 8)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: compare (pebble)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x, 7)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x, 8)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: compare (pebble)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x, 7)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x, 8)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: compare (pebble)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x, 7)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x, 8)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: compare (pebble)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x, 7)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x, 8)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: compare (pebble)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x, 7)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x, 8)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: compare (pebble)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x, 7)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x, 8)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
🔇 Additional comments (11)
coherence/README.md (1)
20-27: Context-aware method signatures look correct and align with other driversThe addition of
*WithContextvariants mirrors the pattern adopted in the other storage adapters and keeps the original non-context methods as thin wrappers. No inconsistencies spotted in the receiver/type list or parameter ordering.cloudflarekv/README.md (1)
12-13: Re-evaluate the stated minimum Go versionThe note still says “Requires Go 1.21 and above”, whereas project discussion (see PR comments) targets “last two Go versions” (currently 1.23 & 1.24). Updating this line avoids confusion about supported versions.
-**Note: Requires Go 1.21 and above** +**Note: Requires Go 1.23 and above**aerospike/README.md (1)
27-34: README signature additions look goodThe new
*WithContextmethod signatures match the convention adopted across the other drivers and clearly expose the new API surface.
No further action required.leveldb/leveldb.go (6)
4-4: Import addition looks good.The
contextimport is necessary for the new context-aware method signatures.
45-50: Key type change from []byte to string is correctly implemented.The method signature change and internal conversion to byte slice for LevelDB operations is properly handled. This aligns with the broader pattern across storage drivers in this PR.
70-73: Context-aware Get method properly implemented as dummy method.The implementation correctly delegates to the original
Getmethod, which is appropriate given that LevelDB doesn't support context cancellation.
76-94: Key type change and context support correctly implemented for Set method.The string key is properly converted to byte slice in both the non-expiring and expiring value paths. The logic and error handling remain consistent with the original implementation.
96-99: Context-aware Set method properly implemented as dummy method.The implementation correctly delegates to the original
Setmethod, maintaining consistency with the context support approach.
125-128: Context-aware Reset method properly implemented as dummy method.The implementation correctly delegates to the original
Resetmethod, completing the context-aware interface compliance.leveldb/README.md (2)
25-31: Context-aware method signatures correctly documented.The new method signatures are properly documented and match the implementation approach used across storage drivers with limited context support.
36-36: Excellent documentation of context method limitations.The note clearly explains that these are dummy methods without actual functionality, setting appropriate expectations for users while maintaining interface compliance.
ERROR: Wrangler requires at least Node.js v20.0.0. You are using v18.20.8. Please update your version of Node.js.
…into add-withcontext
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
README.md (1)
31-58: Suppress MD010 false-positives for Go code blocksThe hard-tab warnings reported by markdownlint (
MD010) stem from the fact thatgofmtproduces tabs by default. Since this block is a code example, hard tabs are expected and preferable.Either:
- Ignore the warnings, or
- Add a rule override in
.markdownlint.yamlto disableMD010for fencedgoblocks:MD010: code_blocks: falseNo code change required—just lint config.
🧹 Nitpick comments (1)
README.md (1)
25-25: Pluralize “version” for grammatical correctness
...the latest two Go version.→...the latest two Go versions.
A tiny wording tweak avoids a grammatical hiccup.-**Note:** All storages are tested with the latest two [Go version](https://go.dev/doc/devel/release#policy). Older Go versions may also work, but are not guaranteed to be supported. +**Note:** All storages are tested with the latest two [Go versions](https://go.dev/doc/devel/release#policy). Older Go versions may also work, but are not guaranteed to be supported.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
README.md(1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/cache/cache_test.go:897-897
Timestamp: 2024-11-08T04:10:42.990Z
Learning: In the Fiber framework, `Context()` is being renamed to `RequestCtx()`, and `UserContext()` to `Context()` to improve clarity and align with Go's context conventions.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: itssimon
PR: gofiber/recipes#3108
File: monitoring-with-apitally/main.go:90-105
Timestamp: 2025-05-14T01:04:10.042Z
Learning: In recipe examples for the gofiber/recipes repository, it's acceptable to have placeholder comments for business logic (like data storage) when the primary focus is on demonstrating a specific integration or feature (such as Apitally monitoring).
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/adaptor/adaptor.go:111-111
Timestamp: 2024-11-10T23:44:13.704Z
Learning: In the `middleware/adaptor/adaptor.go` file of the Fiber framework, when updating context handling, replacing `c.Context()` with `c.RequestCtx()` is appropriate to access the `fasthttp.RequestCtx`.
Learnt from: ReneWerner87
PR: gofiber/contrib#0
File: :0-0
Timestamp: 2024-11-29T15:24:06.083Z
Learning: When customizing the Fiber context to achieve version independence, using generics in methods like `Status` and `Type` allows for fluent method chaining. Implementing a generic interface for `Ctx` on the `App` prevents class switching when registering custom contexts that use fluent methods. Providing multiple `New` methods allows users who do not wish to customize the context to continue using `fiber.New` without changes.
Learnt from: the-real-i9
PR: gofiber/storage#1562
File: neo4j/neo4j.go:50-52
Timestamp: 2025-01-30T12:29:41.774Z
Learning: Storage drivers in the gofiber/storage repository intentionally panic on connection errors as a design choice to fail fast when storage is unavailable.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/server/server.go:14-16
Timestamp: 2024-11-23T19:50:41.765Z
Learning: In the `clean-code` example at `clean-code/app/server/server.go` using the Go Fiber framework, it's acceptable to omit production-level features like context usage and graceful shutdown handling to keep the example simple.
Learnt from: efectn
PR: gofiber/fiber#3162
File: app_test.go:893-895
Timestamp: 2024-11-29T12:37:27.581Z
Learning: In the `Test_App_ShutdownWithContext` function in `app_test.go`, the `clientDone` channel is used to synchronize the client's request completion before proceeding, eliminating the need for additional `time.Sleep` calls.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/db_mock.go:13-19
Timestamp: 2024-11-23T19:50:06.387Z
Learning: In test code within `clean-code/app/datasources/database/db_mock.go`, adding safety checks like context validation, safe type assertions, and extra documentation is not necessary.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:106-107
Timestamp: 2024-07-01T15:49:51.308Z
Learning: The `IsZero` function for `time.Time` structs in the ClickHouse storage driver was returning false even for zero value `time.Time` structs. As a result, a different verification logic was implemented to avoid bugs.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:106-107
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The `IsZero` function for `time.Time` structs in the ClickHouse storage driver was returning false even for zero value `time.Time` structs. As a result, a different verification logic was implemented to avoid bugs.
README.md (13)
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/cache/cache_test.go:897-897
Timestamp: 2024-11-08T04:10:42.990Z
Learning: In the Fiber framework, `Context()` is being renamed to `RequestCtx()`, and `UserContext()` to `Context()` to improve clarity and align with Go's context conventions.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: gaby
PR: gofiber/storage#1638
File: surrealdb/surrealdb.go:34-43
Timestamp: 2025-05-01T11:46:33.057Z
Learning: In the gofiber/storage package, storage drivers should panic when encountering database connection failures during initialization rather than returning errors. This is an intentional design pattern to ensure applications fail fast and explicitly when critical database dependencies are unavailable.
Learnt from: ReneWerner87
PR: gofiber/storage#0
File: :0-0
Timestamp: 2025-02-12T11:24:31.153Z
Learning: The storage package in gofiber/storage repository can be used independently of the Fiber web framework.
Learnt from: the-real-i9
PR: gofiber/storage#1562
File: neo4j/neo4j.go:50-52
Timestamp: 2025-01-30T12:29:41.774Z
Learning: Storage drivers in the gofiber/storage repository intentionally panic on connection errors as a design choice to fail fast when storage is unavailable.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/memory_db.go:0-0
Timestamp: 2024-11-25T19:31:39.216Z
Learning: The `memoryDB` implementation in `clean-code/app/datasources/database/memory_db.go` is not intended for production use, so input validation, concurrency protection, and context usage are not required in this file.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:114-115
Timestamp: 2024-07-01T15:47:48.701Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, MongoDB, and Clickhouse.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:114-115
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, MongoDB, and Clickhouse.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: luk3skyw4lker
PR: gofiber/storage#1342
File: clickhouse/clickhouse.go:57-58
Timestamp: 2024-07-26T21:00:12.902Z
Learning: The pattern of returning `nil` for empty keys or values is consistent across different storage drivers in the gofiber/storage repository, including Redis, Rueidis, and MongoDB.
Learnt from: norri
PR: gofiber/recipes#2701
File: clean-code/app/datasources/database/memory_db.go:18-20
Timestamp: 2024-11-25T19:31:36.658Z
Learning: In `clean-code/app/datasources/database/memory_db.go`, the `memoryDB` implementation is intended as an example and not for production use.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:16-26
Timestamp: 2024-09-25T16:17:00.969Z
Learning: In the session middleware `Config` struct, `Store` is backed by `fiber.Storage`; they are different entities serving distinct purposes in session management.
🪛 markdownlint-cli2 (0.17.2)
README.md
31-31: Hard tabs
Column: 1
(MD010, no-hard-tabs)
32-32: Hard tabs
Column: 1
(MD010, no-hard-tabs)
33-33: Hard tabs
Column: 1
(MD010, no-hard-tabs)
35-35: Hard tabs
Column: 1
(MD010, no-hard-tabs)
36-36: Hard tabs
Column: 1
(MD010, no-hard-tabs)
37-37: Hard tabs
Column: 1
(MD010, no-hard-tabs)
39-39: Hard tabs
Column: 1
(MD010, no-hard-tabs)
40-40: Hard tabs
Column: 1
(MD010, no-hard-tabs)
41-41: Hard tabs
Column: 1
(MD010, no-hard-tabs)
43-43: Hard tabs
Column: 1
(MD010, no-hard-tabs)
44-44: Hard tabs
Column: 1
(MD010, no-hard-tabs)
45-45: Hard tabs
Column: 1
(MD010, no-hard-tabs)
46-46: Hard tabs
Column: 1
(MD010, no-hard-tabs)
48-48: Hard tabs
Column: 1
(MD010, no-hard-tabs)
49-49: Hard tabs
Column: 1
(MD010, no-hard-tabs)
50-50: Hard tabs
Column: 1
(MD010, no-hard-tabs)
52-52: Hard tabs
Column: 1
(MD010, no-hard-tabs)
53-53: Hard tabs
Column: 1
(MD010, no-hard-tabs)
54-54: Hard tabs
Column: 1
(MD010, no-hard-tabs)
56-56: Hard tabs
Column: 1
(MD010, no-hard-tabs)
57-57: Hard tabs
Column: 1
(MD010, no-hard-tabs)
59-59: Hard tabs
Column: 1
(MD010, no-hard-tabs)
60-60: Hard tabs
Column: 1
(MD010, no-hard-tabs)
62-62: Hard tabs
Column: 1
(MD010, no-hard-tabs)
63-63: Hard tabs
Column: 1
(MD010, no-hard-tabs)
64-64: Hard tabs
Column: 1
(MD010, no-hard-tabs)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (113)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x, 6)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x, 6)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x, 6)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x, 6)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x, 6)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x, 6)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x, 6)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x, 6)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x, 6)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.23.x)
- GitHub Check: Tests (1.24.x)
- GitHub Check: Tests (1.24.x, 6)
4 participants
This PR adds context management support to support as a part of gofiber/fiber#2839
Todo List:
Summary by CodeRabbit
Summary by CodeRabbit