Tags: gofr-dev/gofr
Tags
Release v1.56.7 (#3525) * chore(deps): consolidate minor dependency updates Updates included: - google.golang.org/api: 0.277.0 -> 0.279.0 - golang.org/x/crypto: 0.49.0 -> 0.51.0 - github.com/elastic/go-elasticsearch/v8: 8.19.5 -> 8.19.6 - google.golang.org/grpc: 1.81.0 -> 1.81.1 - github.com/nats-io/nats.go: 1.49.0 -> 1.52.0 - github.com/nats-io/nats-server/v2: 2.11.15 -> 2.14.0 - cloud.google.com/go/storage: 1.62.1 -> 1.62.2 - github.com/Azure/azure-sdk-for-go/sdk/storage/azfile: 1.5.4 -> 1.6.0 - github.com/Azure/azure-sdk-for-go/sdk/storage/azblob: 1.6.3 -> 1.7.0 - github.com/alicebob/miniredis/v2: 2.37.0 -> 2.38.0 - crate-ci/typos (GitHub Action): 1.46.1 -> 1.46.2 Applied across the root module and all affected datasource submodules. Closes: #3432, #3433, #3434, #3435, #3436, #3437, #3438, #3439, #3440, #3441, #3442, #3443, #3444, #3445, #3446, #3447, #3448, #3449, #3450, #3451, #3452 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chore(deps): regenerate JetStream mock for nats.go v1.52.0 nats.go v1.52.0 added ResetConsumer / ResetConsumerToSequence on both the JetStream and Stream interfaces, breaking the previously-generated MockJetStream. Regenerated via: mockgen -destination=mock_jetstream.go -package=nats \ github.com/nats-io/nats.go/jetstream \ JetStream,Stream,Consumer,Msg,MessageBatch Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * perf: HTTP hot-path optimizations — alloc/CPU reductions in middleware, router, OTel setup (#3431) * chore(deps): consolidate minor dependency updates (#3491) Updates included: - google.golang.org/api: 0.279.0 -> 0.280.0 - github.com/aws/aws-sdk-go-v2/service/dynamodb: 1.57.3 -> 1.57.4 - github.com/couchbase/gocb/v2: 2.12.2 -> 2.12.3 - github.com/nats-io/nats-server/v2: 2.14.0 -> 2.14.1 - github.com/aws/aws-sdk-go-v2/config: 1.32.17 -> 1.32.18 - golang.org/x/crypto: 0.51.0 -> 0.52.0 - github.com/aws/aws-sdk-go-v2/credentials: 1.19.16 -> 1.19.17 - gofr.dev (submodules): 1.56.4 -> 1.56.6 - crate-ci/typos action: 1.46.2 -> 1.46.3 Closes: #3490, #3489, #3488, #3487, #3486, #3485, #3484, #3483, #3482, #3481, #3480, #3479, #3478, #3477, #3476, #3475, #3474, #3473, #3472, #3471, #3470, #3469, #3468, #3467, #3466, #3465, #3464, #3463, #3462 * chore(deps): consolidate minor dependency updates (#3524) * update release version to v1.56.7 --------- Co-authored-by: Aryan Mehrotra <aryanmehrotra2000@gmail.com>
v1.56.1 (#3295) * fix: resolve busy-spin, goroutine leak, and deadlock in Redis stream subscription subscribeToStream had three interconnected bugs: 1. Busy-spin when channel full: consumeStreamMessages returned immediately when getAvailableCapacity was 0, causing the for/select loop to spin at full CPU. Fixed by returning a bool and adding a time.After backoff (using the existing subscribeRetryInterval constant). 2. Goroutine leak via uncancelable context: ensureSubscription discarded the derived context (_ , cancel := context.WithCancel(...)) and runSubscriptionLoop used a fresh context.Background(). The ctx.Done() check in subscribeToStream could never fire. Fixed by storing and propagating the cancelable context through the call chain. 3. Deadlock in Close(): Close() held ps.mu.Lock() while calling waitForAllGoroutines(), but goroutines needed ps.mu.RLock() to exit. Fixed by collecting WaitGroups under the lock, releasing it, waiting, then re-acquiring for cleanup. Same fix applied to cleanupStreamConsumers. Also made runSubscriptionLoop's retry delay context-aware (select on ctx.Done + time.After instead of bare time.Sleep). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: also fix resubscribeAll for streams — was silently broken resubscribeAll discarded the new context (_ , newCancel := ...) and never started a new goroutine. After our context propagation fix, the old goroutine exits cleanly on cancel but nothing replaces it. Fix: cancel old contexts → wait for goroutines outside the lock → re-acquire lock → start new goroutines with fresh cancelable contexts. Added TestPubSub_ResubscribeAll_StreamMode_RestartsGoroutine which verifies the goroutine restarts and can receive messages after resubscription. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * test: add integration tests validating fixes against real Redis 6 integration tests (build tag: integration) that run against a real Redis instance to validate all fixes end-to-end: - BusySpinFix: goroutine count stays stable with full channel - CloseNoDeadlock: Close() completes in ~800ms (not 5s+ deadlock) - CloseFullChannelNoDeadlock: same with full channel (original trigger) - PublishSubscribeEndToEnd: 5/5 messages flow correctly - ResubscribeAllStreams: goroutine restarts, messages flow after resub - MultipleTopicsCloseCleanly: 3 concurrent topics close in ~700ms Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: preserve consumer name across resubscribes to prevent PEL data loss After resubscribeAll, subscribeToStream generated a new consumer name (unique per timestamp). This orphaned PEL entries under the old consumer name — unACKed messages were never redelivered. Fix: getOrCreateConsumerName reuses the existing consumer name stored in streamConsumers if one exists for the topic. This preserves PEL ownership so the new goroutine picks up unACKed messages. Added TestIntegration_ResubscribePreservesData which: 1. Publishes 3 messages, drains them WITHOUT committing (stays in PEL) 2. Triggers resubscribeAll 3. Verifies all 3 messages are redelivered from PEL Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Co-authored-by: Umang Mundhra <mundhraumang.02@gmail.com>
PreviousNext