chore(deps): update module google.golang.org/grpc to v1.83.1 [security] (main)

[renovate]

This PR contains the following updates:

Package	Type	Update	Change	OpenSSF
google.golang.org/grpc	indirect	minor	v1.80.0 → v1.83.1

---

gRPC-Go: xDS RBAC and HTTP/2 Vulnerabilities

GHSA-hrxh-6v49-42gf / GO-2026-6061

More information

Details

Multiple security vulnerabilities have been identified and addressed in grpc-go affecting the xDS RBAC authorization engine (internal/xds/rbac) and the HTTP/2 transport server implementation (internal/transport). These vulnerabilities could result in:

• Authorization Bypass (Fail-Open) when translating xDS RBAC policies containing Metadata or RequestedServerName fields.
• Denial of Service (High CPU Consumption) due to an HTTP/2 Rapid Reset mitigation bypass during client-initiated stream resets.
• Denial of Service (Server Panic) when parsing crafted xDS RBAC policies containing NOT rules around unsupported fields.

Impact

What kind of vulnerability is it? Who is impacted?

xDS RBAC Authorization Bypass via Metadata & RequestedServerName matchers

• Affected Component: xDS RBAC
• Impact: When building policy matchers for gRPC RBAC from xDS configurations, unsupported permission and principal rules (specifically Metadata and RequestedServerName) were silently ignored and treated as no-ops.
  • If an authorization policy relied purely on these matchers for access control, treating those rules as no-ops effectively removed the restrictions.
• If these unsupported rules were nested inside logical NOT rules (Permission_NotRule / Principal_NotId) or multi-condition OR/AND rules, silently dropping them changed the boolean logic flow of the authorization engine.

As a result, policy evaluation decisions could fail open, allowing unauthorized clients to access protected gRPC services or resources.

HTTP/2 Rapid Reset Mitigation Bypass / Denial of Service via Stream Aborts

• Affected Component: HTTP/2 transport
• Impact: Earlier mitigations in grpc-go for HTTP/2 Rapid Reset only applied threshold checks to items that directly resulted in control frames being written back to the wire, such as SETTINGS ACKs or server-initiated RST_STREAMs.

When a client initiated a rapid flood of stream creation (HEADERS) immediately followed by stream termination RST_STREAM, items queued up in the control buffer without counting against the transport response frame threshold. An attacker can repeatedly trigger this flood sequence to bypass reader blocking, resulting in high CPU usage, and Denial of Service (DoS).

Denial of Service (Panic) in xDS RBAC Engine via Unsupported Fields inside NOT Rules

• Affected Component: xDS RBAC
• Impact: The xDS RBAC policy translators recursively generate matchers for nested rules. When a NOT rule wrapped an unsupported or unhandled field (such as SourcedMetadata), the recursive step returned an empty matcher. This could result in a runtime panic when the RBAC engine attempts to authorize an incoming request.

An attacker or misconfigured/malicious xDS management server delivering an LDS/RDS update containing a NOT rule around an unhandled field causes the gRPC server process to crash immediately (CWE-248 / Denial of Service).

Patches

Has the problem been patched? What versions should users upgrade to?

All three issues have been fixed in master and will be released in 1.82.1 shortly.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

If upgrading grpc-go immediately is not possible, apply the following workarounds based on your deployment architecture:

• For xDS RBAC Vulnerabilities & Panics: Ensure that upstream xDS management servers do not push RBAC policies containing Metadata, RequestedServerName, or NOT rules wrapping unsupported fields (such as SourcedMetadata) to grpc-go servers.
• For HTTP/2 Rapid Reset DOS: Configure upstream reverse proxies or load balancers (such as Envoy) with strict HTTP/2 max_concurrent_streams limits and active rate limiting on RST_STREAM frequency per connection.

Severity

Vulnerability	Qualitative Severity	Approximate CVSS v3.1 Score	Primary Impact
xDS RBAC Authorization Bypass	High	8.2	Unauthorized Access / Fail-Open
HTTP/2 Rapid Reset DOS Bypass	High	7.5	High CPU Consumption / Denial of Service
xDS RBAC Engine Server Panic	Medium	5.9	Process Crash / Denial of Service

Severity

• CVSS Score: 8.8 / 10 (High)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N

References

• https://github.com/grpc/grpc-go/security/advisories/GHSA-hrxh-6v49-42gf
• https://github.com/grpc/grpc-go/pull/9236
• https://github.com/grpc/grpc-go/commit/4ea465d4ab98013f72a142fe0fc89c19770b2935
• https://github.com/grpc/grpc-go
• https://github.com/grpc/grpc-go/releases/tag/v1.82.1

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

Vulnerabilities in the xDS RBAC authorization engine and the HTTP/2 transport server implementation in google.golang.org/grpc

GHSA-hrxh-6v49-42gf / GO-2026-6061

More information

Details

Vulnerabilities in the xDS RBAC authorization engine and the HTTP/2 transport server implementation in google.golang.org/grpc

Severity

Unknown

References

• https://github.com/grpc/grpc-go/security/advisories/GHSA-hrxh-6v49-42gf
• https://github.com/grpc/grpc-go/commit/4ea465d4ab98013f72a142fe0fc89c19770b2935
• https://github.com/grpc/grpc-go/pull/9236
• https://github.com/grpc/grpc-go/releases/tag/v1.82.1

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

---

gRPC-Go xDS servers: Denial of Service (DoS) via crash due to missing :authority and Host headers

CVE-2026-84445 / GHSA-2v4p-qf9q-27wj / GO-2026-6443

More information

Details

A vulnerability exists in gRPC-Go servers configured with xds.NewGRPCServer() where a crafted request missing both :authority and Host headers can cause a server panic, resulting in a Denial of Service (DoS).

Servers built with xds.NewGRPCServer install an xDS routing interceptor on every RPC. This interceptor looks up the request’s :authority header to pick a virtual host. The HTTP/2 server transport previously accepted requests that had neither :authority nor Host. When this happened, the xDS routing interceptor attempted to access the first element of an empty slice of authorities, leading to an index out of bounds panic. Since the per-RPC goroutine does not recover from panics, the entire server process would terminate.

This panic occurs in the interceptor pipeline, meaning the transport credentials handshake (TLS, mTLS, or ALTS) and HTTP/2 connection establishment must complete successfully before the crafted request can reach this logic.

• Insecure/Standard TLS: If the server permits insecure (plaintext) connections or standard credentials (where client certs are not checked), any unauthenticated remote attacker can trigger the crash.
• mTLS / ALTS: If strict transport-level authentication is enforced at the network edge or transport layer (e.g., requiring a valid client certificate), the attacker must possess valid transport credentials to initiate the stream and trigger the panic.

Impact

An attacker can cause a complete outage of the gRPC server by sending a request missing both :authority and Host headers, provided they can successfully establish a transport connection.

Patches

The issue has been addressed in master (and backported to 1.84.0, 1.83.2 and 1.82.2). The fix updates the HTTP/2 transport layer to reject requests missing both :authority and Host headers early, maintaining consistency with and other gRPC language implementations.

Severity

• CVSS Score: 8.7 / 10 (High)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

References

• https://github.com/grpc/grpc-go/security/advisories/GHSA-2v4p-qf9q-27wj
• https://nvd.nist.gov/vuln/detail/CVE-2026-84445
• https://github.com/grpc/grpc-go/issues/9354
• https://github.com/grpc/grpc-go/pull/9365
• https://github.com/grpc/grpc-go/pull/9366
• https://github.com/grpc/grpc-go/pull/9367
• https://github.com/grpc/grpc-go/commit/3822494d8ea03b992c089fd2a195f041762fffb7
• https://github.com/grpc/grpc-go/commit/8668b69c167df908b6b3666dcbf40992b9e932a4
• https://github.com/grpc/grpc-go/commit/93e31b48545e2a8aaeb6e06b47fb249f94e6297f
• https://github.com/grpc/grpc-go
• https://github.com/grpc/grpc-go/releases/tag/v1.82.2
• https://github.com/grpc/grpc-go/releases/tag/v1.83.2

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

Server panic via missing authority or Host headers in google.golang.org/grpc

CVE-2026-84445 / GHSA-2v4p-qf9q-27wj / GO-2026-6443

More information

Details

In google.golang.org/grpc, servers configured with xDS routing can panic when processing requests that lack both :authority and Host headers. The HTTP/2 transport layer accepted requests missing these headers, and the xDS server routing interceptor attempted to index the empty authority slice, causing an unhandled panic and terminating the server.

Severity

Unknown

References

• https://github.com/grpc/grpc-go/security/advisories/GHSA-2v4p-qf9q-27wj
• https://github.com/grpc/grpc-go/issues/9354
• https://github.com/grpc/grpc-go/pull/9365

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

---

gRPC-Go: xDS RBAC HTTP Filter bypass via mixed-case Header Matching and gRFC A41 validation evasion

CVE-2026-84303 / GHSA-qc2q-p7wx-3px3 / GO-2026-6441

More information

Details

Summary

A vulnerability in the xDS RBAC HTTP filter implementation in grpc-go allows remote attackers to bypass authorization policies (specifically DENY rules) by using mixed-case or canonical-case header matchers (e.g., X-Role instead of x-role). Additionally, the safety guards introduced by gRFC A41 to block grpc- prefixed headers can be evaded via variations in casing (e.g., Grpc-Status).

Impact

When an operator defines an RBAC policy referencing headers containing uppercase letters (e.g. X-Role), grpc-go fails to match incoming metadata keys because they are unconditionally lowercased. Because of this case-sensitivity mismatch, a policy designed to block requests containing specific header values fails open: the rule is evaluated as a non-match, and traffic that should have been rejected is served.

Furthermore, gRFC A41 requires rejecting configuration schemas specifying header matchers starting with grpc-. Because this check is executed case-sensitively in grpc-go, attackers can bypass the validation by specifying titles like Grpc-Status.

Patches

The problem is fixed in master and in the 1.83.1 release.

Severity

• CVSS Score: 6.3 / 10 (Medium)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

References

• https://github.com/grpc/grpc-go/security/advisories/GHSA-qc2q-p7wx-3px3
• https://nvd.nist.gov/vuln/detail/CVE-2026-84303
• https://github.com/grpc/grpc-go/pull/9332
• https://github.com/grpc/grpc-go/pull/9335
• https://github.com/grpc/grpc-go/commit/db9482836c298f234c896cf82ab68cafc78237f8
• https://github.com/grpc/grpc-go/commit/ebba6f3f1b206e2b4dc4d1d5a96d18430302c2fe
• https://github.com/grpc/grpc-go
• https://github.com/grpc/grpc-go/releases/tag/v1.83.1

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

gRPC-Go: Heap Memory Exhaustion (OOM) via HTTP/2 DATA Frame Fragmentation

CVE-2026-84304 / GHSA-vp52-pcj8-j9qc / GO-2026-6348

More information

Details

Impact

An unauthenticated remote attacker can initiate a gRPC stream and purposefully fragment their payload into millions of tiny (e.g., 1-byte) HTTP/2 DATA frames. Even if the total payload volume falls within the configured connection and stream flow-control windows, each independent fragment incurs memory overhead due to internal tracking structures and queue allocation.

Repeated fragmentation massively inflates the heap space consumed by the stream. An attacker multiplexing multiple concurrent streams can exhaust the memory bounds of the runtime, forcing a runtime panic or OutOfMemory condition and leading to a remote Denial of Service (DoS).

Patches

The change to fix this issue is merged in master and a patch release, 1.83.1, has been published that contains this fix.

Workarounds

This vulnerability is mitigated by implementing receive buffer compaction. Consecutive small data buffers are automatically coalesced into larger buffers from a shared pool once the overhead is perceived to be excessive relative to actual payload data, drastically minimizing per-frame memory overheads.

This behavior is enabled by default. A temporary escape hatch is provided via the environment variable GRPC_GO_EXPERIMENTAL_ENABLE_RECEIVE_BUFFER_COMPACTION=false to disable the feature if unforeseen issues arise, but it will be removed in a future release.

Severity

• CVSS Score: 8.7 / 10 (High)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

• https://github.com/grpc/grpc-go/security/advisories/GHSA-vp52-pcj8-j9qc
• https://nvd.nist.gov/vuln/detail/CVE-2026-84304
• https://github.com/grpc/grpc-go/pull/9331
• https://github.com/grpc/grpc-go/pull/9333
• https://github.com/grpc/grpc-go/commit/7354d9c8debb4bcf2225bf429857078de310c176
• https://github.com/grpc/grpc-go/commit/8cfeca0e1ee5ea0980dcc320e20240fa1079ec77
• https://github.com/grpc/grpc-go
• https://github.com/grpc/grpc-go/releases/tag/v1.83.1

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

Heap Memory Exhaustion (OOM) via HTTP/2 DATA Frame Fragmentation in google.golang.org/grpc

CVE-2026-84304 / GHSA-vp52-pcj8-j9qc / GO-2026-6348

More information

Details

Heap Memory Exhaustion (OOM) via HTTP/2 DATA Frame Fragmentation in google.golang.org/grpc

Severity

Unknown

References

• https://github.com/grpc/grpc-go/security/advisories/GHSA-vp52-pcj8-j9qc
• https://github.com/grpc/grpc-go/commit/7354d9c8debb4bcf2225bf429857078de310c176
• https://github.com/grpc/grpc-go/commit/8cfeca0e1ee5ea0980dcc320e20240fa1079ec77
• https://github.com/grpc/grpc-go/pull/9331
• https://github.com/grpc/grpc-go/pull/9333
• https://github.com/grpc/grpc-go/releases/tag/v1.83.1

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

---

Bypass of xDS RBAC HTTP filter header matching in google.golang.org/grpc

CVE-2026-84303 / GHSA-qc2q-p7wx-3px3 / GO-2026-6441

More information

Details

In google.golang.org/grpc, the xDS RBAC HTTP filter does not lowercase header matcher names before evaluating them against incoming request metadata. When an RBAC policy defines rules (such as DENY) referencing headers with uppercase or mixed-case characters, the rule fails to match, causing authorization policies to fail open. Additionally, callers can evade gRFC A41 validation blocking "grpc-" prefixed headers and ":scheme" via variations in casing.

Severity

Unknown

References

• https://github.com/grpc/grpc-go/security/advisories/GHSA-qc2q-p7wx-3px3
• https://github.com/grpc/grpc-go/pull/9332

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

---

Release Notes

grpc/grpc-go (google.golang.org/grpc)

v1.83.1: Release 1.83.1

Compare Source

Security

• xds/rbac: Fix a bug where nested Principal or Permission rules with :scheme or grpc- prefixed header matchers were not rejected, which could cause DENY rules to fail open. (#​9258)
  • Special Thanks: @​nvxbug
• xds/rbac: Fix a bug where the host header matcher was not being replaced with :authority in nested Principal or Permission rules. (#​9258)
  • Special Thanks: @​nvxbug
• xds/rbac: Fix a bug where a header matcher whose name was not lowercase, such as X-Role, matched no header, which could cause DENY rules to fail open. (#​9332)
  • Special Thanks: @​alimony
• xds/rbac: Fix a bug where a :scheme or grpc- prefixed header matcher was accepted when its name was not lowercase. (#​9332)
  • Special Thanks: @​alimony
• xds/rbac: Fix a bug where a Host header matcher was not replaced with :authority. (#​9332)
  • Special Thanks: @​alimony

Performance

• transport: Restrict memory overhead of buffering small data frames. (#​9331)

v1.83.0: Release 1.83.0

Compare Source

Security

• server: Stop reading from connections when flooded by HTTP/2 frames to mitigate resource exhaustion. The default value for this limit is 100 frames, excluding DATA and HEADERS, and may be changed by setting environment variable GRPC_GO_EXPERIMENTAL_CONTROL_BUFFER_THROTTLE_LIMIT.
• xds/rbac: Support Metadata and RequestedServerName permissions matcher fields. If present in a DENY rule, previously these would be ignored and fail-open.
• xds/rbac: Fix panic when parsing unsupported fields in NotRule/NotId permissions.
• xds/rbac: Support the deprecated source_ip principal identifier by treating it as equivalent to direct_remote_ip.
• xds: Fix panic when parsing route header matchers configured with empty exact_match, prefix_match, or suffix_match strings. (#​9223)

New Features

• xds/googlec2p: Enable DirectPath over Interconnect support for on-premises clients via the force-xds target URI query parameter. (#​9133)
• xds: Enable xDS configuration to control which fields get propagated from ORCA backend metric reports to LRS load reports. (#​9145)
• authz: Add OnPolicyUpdate callback to FileWatcherOptions to notify when an authz policy is loaded or updated. (#​9142)
  • Special Thanks: @​hnefatl
• xds: Add support for the GCP Authentication HTTP Filter, which automatically fetches and attaches GCP Service Account Identity JWT tokens to outgoing RPCs.
  • This feature can be enabled by setting environment variable GRPC_EXPERIMENTAL_XDS_GCP_AUTHENTICATION_FILTER=true. (#​9119)
• xds: Add support for xDS-based HTTP CONNECT proxies.
  • This feature can be enabled by setting environment variable GRPC_EXPERIMENTAL_XDS_HTTP_CONNECT=true. (#​9151)
• xds: Add support for contains_match in route header matchers. (#​9223)

Bug Fixes

• credentials/alts: Fix panic when processing malformed frames by validating that the message frame length exceeds the message type field size. (#​9197)
• grpc: Fix compilation on Plan 9 targets (GOOS=plan9), broken since v1.81.0. (#​9255)
  • Special Thanks: @​Yusufihsangorgel

v1.82.2: Release 1.82.2

Compare Source

Security

• server: Reject requests missing both :authority and Host headers with HTTP 400 and status Internal. (#​9365)
  • Special Thanks: @​winklemad

v1.82.1: Release 1.82.1

Compare Source

Security

• server: Stop reading from the connection when flooded by HTTP/2 frames. The default value for this limit is 100 frames, excluding DATA and HEADERS, and may be changed by setting environment variable GRPC_GO_EXPERIMENTAL_CONTROL_BUFFER_THROTTLE_LIMIT.
• xds/rbac: Support Metadata and RequestedServerName permissions matcher fields. If present in a DENY rule, previously these would be ignored and fail-open.
• xds/rbac: Fix panic when parsing unsupported fields in NotRule/NotId permissions.
• xds/rbac: Support the deprecated source_ip principal identifier by treating it as equivalent to direct_remote_ip.

v1.82.0: Release 1.82.0

Compare Source

Behavior Changes

• server: Remove support for GRPC_GO_EXPERIMENTAL_DISABLE_STRICT_PATH_CHECKING environment varibale. Strict incoming RPC path validation (which has been the default since v1.79.3) can no longer be disabled. (#​9112)
• transport: Add environment variable to change the default max header list size from 16MB to 8KB. This may be enabled by setting GRPC_GO_EXPERIMENTAL_ENABLE_8KB_DEFAULT_HEADER_LIST_SIZE=true. This will be enabled by default in a subsequent release. (#​9019)
• balancer: Load Balancing policy registry is now case-sensitive. Set GRPC_GO_EXPERIMENTAL_CASE_SENSITIVE_BALANCER_REGISTRIES=false (and file an issue) to revert to case-insensitive behavior. (#​9017)

New Features

• experimental/stats: Expose a new API, NewContextWithLabelCallback, to register a callback that is invoked when telemetry labels are added. (#​8877)
  • Special Thanks: @​seth-epps
• client: Return a portion of the response body in the error message, when the client receives an unexpected non-gRPC HTTP response, to make debugging easier. (#​8929)
  • Special Thanks: @​chengxilo
• server: Add environment variable GRPC_GO_SERVER_GOROUTINE_LABELS that controls setting runtime/pprof.Labels on goroutines spawned by the server. Set GRPC_GO_SERVER_GOROUTINE_LABELS=grpc.method=true to add the grpc.method label on goroutines spawned to handle incoming requests. (#​9082)
  • Special Thanks: @​dfinkel

Bug Fixes

• xds/server: Fix a memory leak of HTTP filter instances occurring when route configurations are updated in-place during a Route Discovery Service (RDS) update. (#​9138)
• grpc: In the deprecated gzip Compressor (used via the deprecated WithCompressor dial option), enforce the MaxRecvMsgSize limit on the decompressed message buffer, preventing excessive memory allocation from highly compressed payloads. (#​9114)
  • Special Thanks: @​evilgensec
• stats/opentelemetry: Record retry attempts, grpc.previous-rpc-attempts, at the call level and not the attempt level. (#​8923)
• encoding: Ensure Close() is always called on readers returned from Compressor.Decompress if possible. (#​9135)
• channelz: Fix the LastMessageSentTimestamp and LastMessageReceivedTimestamp fields in SocketMetrics to ensure they contain correct timestamp values. (#​9109)

v1.81.1: Release 1.81.1

Compare Source

Security

• xds/rbac: Fix a potential authorization bypass caused by incorrectly falling through URI/DNS SANs to Subject Distinguished Name (DN) when matching the authenticated principal name. With this fix, only the first non-empty identity source will be used, as per gRFC A41. (#​9111)
  • Special Thanks: @​al4an444

Bug Fixes

• otel: Segregate client and server RPC information used for metrics and traces, to avoid one overwriting the other. (#​9081)

v1.81.0: Release 1.81.0

Compare Source

Behavior Changes

• balancer/rls: Switch gauge metrics to asynchronous emission (once per collection cycle) to reduce telemetry noise and align with other gRPC language implementations. (#​8808)

Dependencies

• Minimum supported Go version is now 1.25. (#​8969)

Bug Fixes

• xds: Use the leaf cluster's security config for the TLS handshake instead of the aggregate cluster's config. (#​8956)
• transport: Send a RST_STREAM when receiving an END_STREAM when the stream is not already half-closed. (#​8832)
• xds: Fix ADS resource name validation to prevent a panic. (#​8970)

New Features

• grpc/stats: Add support for custom labels in per-call metrics (gRFC A108). (#​9008)
• xds: Add support for Server Name Indication (SNI) and SAN validation (gRFC A101). Disabled by default. To enable, set GRPC_EXPERIMENTAL_XDS_SNI=true environment variable. (#​9016)
• xds: Add support to control which fields get propagated from ORCA backend metric reports to LRS load reports (gRFC A85). Disabled by default. To enable, set GRPC_EXPERIMENTAL_XDS_ORCA_LRS_PROPAGATION=true. (#​9005)
• xds: Add metrics to track xDS client connectivity and cached resource state (gRFC A78). (#​8807)
• stats/otel: Enhance grpc.subchannel.disconnections metric by adding disconnection reason to the grpc.disconnect_error label (gRFC A94). This provides granular insights into why subchannels are closing. (#​8973)
• mem: Add mem.Buffer.Slice() API to slice the buffer like a slice. (#​8977)
  • Special Thanks: @​ash2k

Performance Improvements

• alts: Pool read buffers to lower memory utilization when sockets are unreadable. (#​8964)
• transport: Pool HTTP/2 framer read buffers to reduce idle memory consumption. Currently limited to Linux for ALTS and non-encrypted transports (TCP, Unix). To disable, set GRPC_GO_EXPERIMENTAL_HTTP_FRAMER_READ_BUFFER_POOLING=false and report any issues. (#​9032)

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[renovate]

ℹ️ Artifact update notice

File name: go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

• 21 additional dependencies were updated

Details:

Package	Change
cel.dev/expr	v0.25.1 -> v0.25.2
github.com/GoogleCloudPlatform/opentelemetry-operations-go/detectors/gcp	v1.31.0 -> v1.33.0
github.com/cncf/xds/go	v0.0.0-20251210132809-ee656c7534f5 -> v0.0.0-20260202195803-dba9d589def2
github.com/envoyproxy/go-control-plane/envoy	v1.36.0 -> v1.37.0
github.com/envoyproxy/protoc-gen-validate	v1.3.0 -> v1.3.3
github.com/spiffe/go-spiffe/v2	v2.6.0 -> v2.7.0
go.opentelemetry.io/contrib/detectors/gcp	v1.39.0 -> v1.44.0
go.opentelemetry.io/otel	v1.43.0 -> v1.44.0
go.opentelemetry.io/otel/metric	v1.43.0 -> v1.44.0
go.opentelemetry.io/otel/sdk	v1.43.0 -> v1.44.0
go.opentelemetry.io/otel/sdk/metric	v1.43.0 -> v1.44.0
go.opentelemetry.io/otel/trace	v1.43.0 -> v1.44.0
golang.org/x/crypto	v0.49.0 -> v0.51.0
golang.org/x/mod	v0.33.0 -> v0.35.0
golang.org/x/net	v0.52.0 -> v0.55.0
golang.org/x/sys	v0.42.0 -> v0.45.0
golang.org/x/term	v0.41.0 -> v0.43.0
golang.org/x/text	v0.35.0 -> v0.37.0
golang.org/x/tools	v0.42.0 -> v0.44.0
google.golang.org/genproto/googleapis/api	v0.0.0-20260401024825-9d38bb4040a9 -> v0.0.0-20260526163538-3dc84a4a5aaa
google.golang.org/genproto/googleapis/rpc	v0.0.0-20260401024825-9d38bb4040a9 -> v0.0.0-20260526163538-3dc84a4a5aaa

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: chore(deps): update module google.golang.org/grpc to v1.83.1 [security] (main) #149
• Branch: renovate/main-go-google.golang.org-grpc-vulnerability
• Command: plan
• SHA: d61bb34
• Repo: devopsfactory-io/neptune

[github-actions]

OpenSSF Scorecard — 7.2/10 ✅

Check	Score	Details
Binary-Artifacts	10/10	no binaries found in the repo
CI-Tests	10/10	29 out of 29 merged PRs checked by a CI test -- score normalized to 10
Code-Review	0/10	Found 0/30 approved changesets -- score normalized to 0
Dangerous-Workflow	10/10	no dangerous workflow patterns detected
License	10/10	license file detected
Pinned-Dependencies	9/10	dependency not pinned by hash detected -- score normalized to 9
Security-Policy	10/10	security policy file detected
Token-Permissions	10/10	GitHub workflow tokens follow principle of least privilege
Vulnerabilities	0/10	31 existing vulnerabilities detected

Threshold: 7 | Full report

[github-actions]

🌊 Neptune Plan Results

Terraform Stacks: stack-a, stack-b

Neptune completed the plan with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform init -input=false (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/local versions matching "~> 2.0"...
- Finding hashicorp/null versions matching "~> 3.0"...
- Installing hashicorp/null v3.3.0...
- Installed hashicorp/null v3.3.0 (signed by HashiCorp)
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform init -input=false (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/null versions matching "~> 3.0"...
- Finding hashicorp/local versions matching "~> 2.0"...
- Installing hashicorp/null v3.3.0...
- Installed hashicorp/null v3.3.0 (signed by HashiCorp)
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-a output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_a will be created
  + resource "null_resource" "stack_a" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-a"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-b output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_b will be created
  + resource "null_resource" "stack_b" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-b"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

To apply these changes, comment:

@neptbot apply

[github-actions]

🌊 Neptune Apply Results

Terraform Stacks: stack-a, stack-b

Neptune completed the apply with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform apply -input=false tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] null_resource.stack_a: Creating...
null_resource.stack_a: Creation complete after 0s [id=8631018306352228273]
local_file.out: Creating...
local_file.out: Creation complete after 0s [id=a57cdd3e7db0022635e46b54e3ae6357944d9ed4]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Command ✅ terraform apply -input=false tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] null_resource.stack_b: Creating...
null_resource.stack_b: Creation complete after 0s [id=753823824723536600]
local_file.out: Creating...
local_file.out: Creation complete after 0s [id=2d8eff4b1ddeb10a7cfb78093bc91edb5b3318f8]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: chore(deps): update module google.golang.org/grpc to v1.83.1 [security] (main) #149
• Branch: renovate/main-go-google.golang.org-grpc-vulnerability
• Command: plan
• SHA: d61bb34
• Repo: devopsfactory-io/neptune

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: chore(deps): update module google.golang.org/grpc to v1.83.1 [security] (main) #149
• Branch: renovate/main-go-google.golang.org-grpc-vulnerability
• Command: plan
• SHA: b400641
• Repo: devopsfactory-io/neptune

[github-actions]

🌊 Neptune Plan Results

Terraform Stacks: stack-a, stack-b

Neptune completed the plan with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform init -input=false (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/null versions matching "~> 3.0"...
- Finding hashicorp/local versions matching "~> 2.0"...
- Installing hashicorp/null v3.3.1...
- Installed hashicorp/null v3.3.1 (signed by HashiCorp)
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform init -input=false (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/null versions matching "~> 3.0"...
- Finding hashicorp/local versions matching "~> 2.0"...
- Installing hashicorp/null v3.3.1...
- Installed hashicorp/null v3.3.1 (signed by HashiCorp)
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-a output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_a will be created
  + resource "null_resource" "stack_a" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-a"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-b output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_b will be created
  + resource "null_resource" "stack_b" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-b"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

To apply these changes, comment:

@neptbot apply

[github-actions]

🌊 Neptune Apply Results

Terraform Stacks: stack-a, stack-b

Neptune completed the apply with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform apply -input=false tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] local_file.out: Creating...
null_resource.stack_a: Creating...
null_resource.stack_a: Creation complete after 0s [id=1295123405225138352]
local_file.out: Creation complete after 0s [id=a57cdd3e7db0022635e46b54e3ae6357944d9ed4]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Command ✅ terraform apply -input=false tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] null_resource.stack_b: Creating...
null_resource.stack_b: Creation complete after 0s [id=8944217182763654515]
local_file.out: Creating...
local_file.out: Creation complete after 0s [id=2d8eff4b1ddeb10a7cfb78093bc91edb5b3318f8]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

[github-actions]

🌊 Neptune Plan Results

Terraform Stacks: stack-a, stack-b

Neptune completed the plan with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform init -input=false (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/null versions matching "~> 3.0"...
- Finding hashicorp/local versions matching "~> 2.0"...
- Installing hashicorp/null v3.3.1...
- Installed hashicorp/null v3.3.1 (signed by HashiCorp)
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform init -input=false (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/local versions matching "~> 2.0"...
- Finding hashicorp/null versions matching "~> 3.0"...
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)
- Installing hashicorp/null v3.3.1...
- Installed hashicorp/null v3.3.1 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-a output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_a will be created
  + resource "null_resource" "stack_a" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-a"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-b output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_b will be created
  + resource "null_resource" "stack_b" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-b"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

To apply these changes, comment:

@neptbot apply

[github-actions]

🌊 Neptune Apply Results

Terraform Stacks: stack-a, stack-b

Neptune completed the apply with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform apply -input=false tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] null_resource.stack_a: Creating...
local_file.out: Creating...
local_file.out: Creation complete after 0s [id=a57cdd3e7db0022635e46b54e3ae6357944d9ed4]
null_resource.stack_a: Creation complete after 0s [id=4334394871940473261]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Command ✅ terraform apply -input=false tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] null_resource.stack_b: Creating...
null_resource.stack_b: Creation complete after 0s [id=4667197112057753325]
local_file.out: Creating...
local_file.out: Creation complete after 0s [id=2d8eff4b1ddeb10a7cfb78093bc91edb5b3318f8]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: chore(deps): update module google.golang.org/grpc to v1.83.1 [security] (main) #149
• Branch: renovate/main-go-google.golang.org-grpc-vulnerability
• Command: plan
• SHA: b400641
• Repo: devopsfactory-io/neptune

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: chore(deps): update module google.golang.org/grpc to v1.83.1 [security] (main) #149
• Branch: renovate/main-go-google.golang.org-grpc-vulnerability
• Command: plan
• SHA: d4771c5
• Repo: devopsfactory-io/neptune

[github-actions]

🌊 Neptune Plan Results

Terraform Stacks: stack-a, stack-b

Neptune completed the plan with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform init -input=false (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/null versions matching "~> 3.0"...
- Finding hashicorp/local versions matching "~> 2.0"...
- Installing hashicorp/null v3.3.1...
- Installed hashicorp/null v3.3.1 (signed by HashiCorp)
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform init -input=false (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/null versions matching "~> 3.0"...
- Finding hashicorp/local versions matching "~> 2.0"...
- Installing hashicorp/null v3.3.1...
- Installed hashicorp/null v3.3.1 (signed by HashiCorp)
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-a output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_a will be created
  + resource "null_resource" "stack_a" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-a"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-b output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_b will be created
  + resource "null_resource" "stack_b" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-b"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

To apply these changes, comment:

@neptbot apply

[github-actions]

🌊 Neptune Plan Results

Terraform Stacks: stack-a, stack-b

Neptune completed the plan with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform init -input=false (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/null versions matching "~> 3.0"...
- Finding hashicorp/local versions matching "~> 2.0"...
- Installing hashicorp/null v3.3.1...
- Installed hashicorp/null v3.3.1 (signed by HashiCorp)
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform init -input=false (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/null versions matching "~> 3.0"...
- Finding hashicorp/local versions matching "~> 2.0"...
- Installing hashicorp/null v3.3.1...
- Installed hashicorp/null v3.3.1 (signed by HashiCorp)
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-a output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_a will be created
  + resource "null_resource" "stack_a" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-a"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-b output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_b will be created
  + resource "null_resource" "stack_b" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-b"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

To apply these changes, comment:

@neptbot apply

[github-actions]

🌊 Neptune Apply Results

Terraform Stacks: stack-a, stack-b

Neptune completed the apply with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform apply -input=false tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] null_resource.stack_a: Creating...
null_resource.stack_a: Creation complete after 0s [id=7176900562387052438]
local_file.out: Creating...
local_file.out: Creation complete after 0s [id=a57cdd3e7db0022635e46b54e3ae6357944d9ed4]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Command ✅ terraform apply -input=false tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] null_resource.stack_b: Creating...
null_resource.stack_b: Creation complete after 0s [id=2556216043076951028]
local_file.out: Creating...
local_file.out: Creation complete after 0s [id=2d8eff4b1ddeb10a7cfb78093bc91edb5b3318f8]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

[github-actions]

🌊 Neptune Apply Results

Terraform Stacks: stack-a, stack-b

Neptune completed the apply with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform apply -input=false tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] null_resource.stack_a: Creating...
null_resource.stack_a: Creation complete after 0s [id=801275975205633585]
local_file.out: Creating...
local_file.out: Creation complete after 0s [id=a57cdd3e7db0022635e46b54e3ae6357944d9ed4]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Command ✅ terraform apply -input=false tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] local_file.out: Creating...
null_resource.stack_b: Creating...
null_resource.stack_b: Creation complete after 0s [id=6002947100074867934]
local_file.out: Creation complete after 0s [id=2d8eff4b1ddeb10a7cfb78093bc91edb5b3318f8]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: chore(deps): update module google.golang.org/grpc to v1.83.1 [security] (main) #149
• Branch: renovate/main-go-google.golang.org-grpc-vulnerability
• Command: plan
• SHA: 66e2424
• Repo: devopsfactory-io/neptune

[github-actions]

🌊 Neptune Plan Results

Terraform Stacks: stack-a, stack-b

Neptune completed the plan with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform init -input=false (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/null versions matching "~> 3.0"...
- Finding hashicorp/local versions matching "~> 2.0"...
- Installing hashicorp/null v3.3.1...
- Installed hashicorp/null v3.3.1 (signed by HashiCorp)
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform init -input=false (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/null versions matching "~> 3.0"...
- Finding hashicorp/local versions matching "~> 2.0"...
- Installing hashicorp/null v3.3.1...
- Installed hashicorp/null v3.3.1 (signed by HashiCorp)
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-a output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_a will be created
  + resource "null_resource" "stack_a" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-a"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-b output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_b will be created
  + resource "null_resource" "stack_b" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-b"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

To apply these changes, comment:

@neptbot apply

[github-actions]

🌊 Neptune Apply Results

Terraform Stacks: stack-a, stack-b

Neptune completed the apply with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform apply -input=false tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] null_resource.stack_a: Creating...
null_resource.stack_a: Creation complete after 0s [id=9182564881923680403]
local_file.out: Creating...
local_file.out: Creation complete after 0s [id=a57cdd3e7db0022635e46b54e3ae6357944d9ed4]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Command ✅ terraform apply -input=false tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] local_file.out: Creating...
null_resource.stack_b: Creating...
local_file.out: Creation complete after 0s [id=2d8eff4b1ddeb10a7cfb78093bc91edb5b3318f8]
null_resource.stack_b: Creation complete after 0s [id=1394774014156428261]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: 36a32865-2a72-4a52-b3fe-2ff1f6a33642

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: chore(deps): update module google.golang.org/grpc to v1.83.1 [security] (main) #149
• Branch: renovate/main-go-google.golang.org-grpc-vulnerability
• Command: plan
• SHA: 66e2424
• Repo: devopsfactory-io/neptune

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: chore(deps): update module google.golang.org/grpc to v1.83.1 [security] (main) #149
• Branch: renovate/main-go-google.golang.org-grpc-vulnerability
• Command: plan
• SHA: b83e673
• Repo: devopsfactory-io/neptune