Conversation
…h calls and retries
…es if present in etag
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds a new hudi-azure module that implements Azure-backed storage locks, credential resolution, config properties, tests, and packaging; registers Azure schemes as supporting storage locks in the core storage schemes enum. Changes
Sequence DiagramssequenceDiagram
participant Client
participant AzureStorageLockClient
participant AzureCredentialFactory
participant BlobServiceClient
participant AzureBlob as "Azure Blob Storage"
Client->>AzureStorageLockClient: tryUpsertLockFile(newLockData, previousLockFile)
AzureStorageLockClient->>AzureCredentialFactory: getAzureCredential(props)
AzureCredentialFactory-->>AzureStorageLockClient: TokenCredential
AzureStorageLockClient->>BlobServiceClient: uploadBlockBlob(content, condition)
alt No prior lock
BlobServiceClient->>AzureBlob: PUT (If-None-Match: *)
else Prior lock
BlobServiceClient->>AzureBlob: PUT (If-Match: <ETag>)
end
alt Success
AzureBlob-->>BlobServiceClient: 200/201 + ETag
BlobServiceClient-->>AzureStorageLockClient: response (ETag)
AzureStorageLockClient-->>Client: (ACQUIRED, StorageLockFile)
else Precondition failed (412)
AzureBlob-->>BlobServiceClient: 412
BlobServiceClient-->>AzureStorageLockClient: BlobStorageException
AzureStorageLockClient-->>Client: (ACQUIRED_BY_OTHERS, None)
end
sequenceDiagram
participant Client
participant AzureStorageLockClient
participant BlobServiceClient
participant AzureBlob as "Azure Blob Storage"
Client->>AzureStorageLockClient: readCurrentLockFile()
AzureStorageLockClient->>BlobServiceClient: downloadStream(blobPath)
BlobServiceClient->>AzureBlob: GET blob
alt Blob exists
AzureBlob-->>BlobServiceClient: 200 + stream + ETag
BlobServiceClient-->>AzureStorageLockClient: stream + headers
AzureStorageLockClient->>AzureStorageLockClient: normalize ETag + parse content
AzureStorageLockClient-->>Client: (SUCCESS, StorageLockFile)
else Blob not found (404)
AzureBlob-->>BlobServiceClient: 404
BlobServiceClient-->>AzureStorageLockClient: BlobStorageException
AzureStorageLockClient-->>Client: (NOT_EXISTS, None)
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~35 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Greptile SummaryThis PR adds Azure Blob Storage / ADLS Gen2 based distributed locking for Hudi tables, mirroring the approach taken for S3 and GCS. It introduces Key changes:
Confidence Score: 4/5Safe to merge with one targeted fix recommended: readCurrentLockFile should handle HoodieLockException consistently The implementation is solid and well-tested. The main concern is the exception-handling inconsistency in readCurrentLockFile — throwing HoodieLockException for null/malformed ETags instead of returning UNKNOWN_ERROR (as tryUpsertLockFile does), while the StorageBasedLockProvider caller has no catch around that call. In normal Azure operation this path is never hit, so it does not affect the happy path. The fix is straightforward and low-risk. The rest of the code (auth factory, URI parsing, conditional writes, caching) is correct and comprehensively tested. hudi-azure/src/main/java/org/apache/hudi/azure/transaction/lock/AzureStorageLockClient.java — specifically the readCurrentLockFile exception handling and the redundant AZURE_SAS_TOKEN constant Important Files Changed
Sequence DiagramsequenceDiagram
participant P as StorageBasedLockProvider
participant C as AzureStorageLockClient
participant B as BlobClient (Azure SDK)
participant Z as Azure Blob Storage
Note over P,Z: Lock Acquisition (tryUpsertLockFile)
P->>C: tryUpsertLockFile(newLockData, previousLockFile)
C->>B: uploadWithResponse(BlobParallelUploadOptions, ...)
Note over C,B: Conditional headers:<br/>If-None-Match:* (create)<br/>If-Match: etag (update)
B->>Z: PUT blob with conditional header
alt 200 OK
Z-->>B: ETag in response
B-->>C: Response BlockBlobItem
C->>C: canonicalizeEtag(etag)
C-->>P: (SUCCESS, StorageLockFile)
else 412 Precondition Failed
Z-->>B: 412
B-->>C: BlobStorageException(412)
C-->>P: (ACQUIRED_BY_OTHERS, empty)
else 409/429/5xx
Z-->>B: error
B-->>C: BlobStorageException
C-->>P: (UNKNOWN_ERROR, empty)
end
Note over P,Z: Lock Read (readCurrentLockFile)
P->>C: readCurrentLockFile()
C->>B: downloadContentWithResponse(...)
B->>Z: GET blob
alt 200 OK
Z-->>B: blob content + ETag header
B-->>C: Response BinaryData
C->>C: canonicalizeEtag(etag)
Note over C: Throws HoodieLockException<br/>if ETag null/malformed
C-->>P: (SUCCESS, StorageLockFile)
else 404 Not Found
Z-->>B: 404
B-->>C: BlobStorageException(404)
C-->>P: (NOT_EXISTS, empty)
else 429/5xx
Z-->>B: error
B-->>C: BlobStorageException
C-->>P: (UNKNOWN_ERROR, empty)
end
Reviews (1): Last reviewed commit: "Revert parquet version" | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| @Override | ||
| public Pair<LockGetResult, Option<StorageLockFile>> readCurrentLockFile() { | ||
| try { | ||
| Response<BinaryData> response = lockBlobClient.downloadContentWithResponse(null, null, null, Context.NONE); | ||
| //Check for null or empty ETag and inconsistent quotes | ||
| String eTag = canonicalizeEtag( | ||
| response.getHeaders() != null ? response.getHeaders().getValue("ETag") : null, | ||
| "download"); | ||
| StorageLockFile lockFile = StorageLockFile.createFromStream(response.getValue().toStream(), eTag); | ||
| return Pair.of(LockGetResult.SUCCESS, Option.of(lockFile)); | ||
| } catch (BlobStorageException e) { | ||
| return Pair.of(handleGetStorageException(e), Option.empty()); | ||
| } | ||
| } |
There was a problem hiding this comment.
readCurrentLockFile can throw HoodieLockException past an unguarded caller
canonicalizeEtag (called at line 244) throws HoodieLockException when the ETag is null, empty, or malformed. Only BlobStorageException is caught here, so that unchecked exception escapes the method. StorageBasedLockProvider.readCurrentLockFile (line 326 in StorageBasedLockProvider.java) calls this with no surrounding try-catch, meaning a corrupt Azure HTTP response will propagate as an unhandled exception and surface as a lock-acquisition failure rather than being gracefully retried.
By contrast, tryUpsertLockFile catches every Exception and maps it to LockUpsertResult.UNKNOWN_ERROR. The same pattern applied here would keep behaviour consistent with the interface's return-value contract:
| @Override | |
| public Pair<LockGetResult, Option<StorageLockFile>> readCurrentLockFile() { | |
| try { | |
| Response<BinaryData> response = lockBlobClient.downloadContentWithResponse(null, null, null, Context.NONE); | |
| //Check for null or empty ETag and inconsistent quotes | |
| String eTag = canonicalizeEtag( | |
| response.getHeaders() != null ? response.getHeaders().getValue("ETag") : null, | |
| "download"); | |
| StorageLockFile lockFile = StorageLockFile.createFromStream(response.getValue().toStream(), eTag); | |
| return Pair.of(LockGetResult.SUCCESS, Option.of(lockFile)); | |
| } catch (BlobStorageException e) { | |
| return Pair.of(handleGetStorageException(e), Option.empty()); | |
| } | |
| } | |
| @Override | |
| public Pair<LockGetResult, Option<StorageLockFile>> readCurrentLockFile() { | |
| try { | |
| Response<BinaryData> response = lockBlobClient.downloadContentWithResponse(null, null, null, Context.NONE); | |
| //Check for null or empty ETag and inconsistent quotes | |
| String eTag = canonicalizeEtag( | |
| response.getHeaders() != null ? response.getHeaders().getValue("ETag") : null, | |
| "download"); | |
| StorageLockFile lockFile = StorageLockFile.createFromStream(response.getValue().toStream(), eTag); | |
| return Pair.of(LockGetResult.SUCCESS, Option.of(lockFile)); | |
| } catch (BlobStorageException e) { | |
| return Pair.of(handleGetStorageException(e), Option.empty()); | |
| } catch (HoodieLockException e) { | |
| logger.error("OwnerId: {}, Malformed or missing ETag in Azure response for lock file: {}", ownerId, lockFileUri, e); | |
| throw e; | |
| } catch (Exception e) { | |
| logger.error("OwnerId: {}, Unexpected error while reading lock file: {}", ownerId, lockFileUri, e); | |
| return Pair.of(LockGetResult.UNKNOWN_ERROR, Option.empty()); | |
| } | |
| } |
At minimum, the explicit re-throw of HoodieLockException (with logging) makes the failure mode obvious at the call site and clearly documents the intentional "fail fast on protocol violation" behaviour.
| private static final int RATE_LIMIT_ERROR_CODE = 429; | ||
| private static final int INTERNAL_SERVER_ERROR_CODE_MIN = 500; | ||
|
|
||
| public static final String AZURE_SAS_TOKEN = AzureStorageLockConfig.AZURE_SAS_TOKEN.key(); |
There was a problem hiding this comment.
AZURE_SAS_TOKEN duplicates AzureStorageLockConfig.AZURE_SAS_TOKEN.key() and is never used internally — the class references AzureStorageLockConfig.AZURE_SAS_TOKEN directly at line 177. Exposing it as a public static final string in this class creates a secondary API surface that callers might depend on, making future refactoring harder without a clear benefit.
Remove the constant entirely; anyone needing the key should use AzureStorageLockConfig.AZURE_SAS_TOKEN.key() directly.
| private BlobServiceClient getBlobServiceClient(AzureLocation location) { | ||
| if (location.blobEndpoint.equals(lockBlobEndpoint)) { | ||
| return blobServiceClient; | ||
| } | ||
| return secondaryBlobServiceClients.computeIfAbsent( | ||
| location.blobEndpoint, | ||
| endpoint -> blobServiceClientSupplier.apply(location.withProperties(clientProperties))); | ||
| } |
There was a problem hiding this comment.
endpoint is shadowed and unused
In the computeIfAbsent lambda, the parameter endpoint (the cache key, equal to location.blobEndpoint) is never referenced — the outer location variable is captured instead. The captured location happens to carry the same endpoint, so correctness is preserved, but the unused parameter is misleading.
| private BlobServiceClient getBlobServiceClient(AzureLocation location) { | |
| if (location.blobEndpoint.equals(lockBlobEndpoint)) { | |
| return blobServiceClient; | |
| } | |
| return secondaryBlobServiceClients.computeIfAbsent( | |
| location.blobEndpoint, | |
| endpoint -> blobServiceClientSupplier.apply(location.withProperties(clientProperties))); | |
| } | |
| private BlobServiceClient getBlobServiceClient(AzureLocation location) { | |
| if (location.blobEndpoint.equals(lockBlobEndpoint)) { | |
| return blobServiceClient; | |
| } | |
| AzureLocation locationWithProps = location.withProperties(clientProperties); | |
| return secondaryBlobServiceClients.computeIfAbsent( | |
| location.blobEndpoint, | |
| endpoint -> blobServiceClientSupplier.apply(locationWithProps)); | |
| } |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
hudi-azure/src/test/java/org/apache/hudi/azure/transaction/lock/TestAzureStorageLockClient.java (2)
264-276: Remove unused variables in test.
dataandjsonare declared but never used in this test since the exception is thrown during ETag validation before the response body is processed.♻️ Proposed cleanup
`@Test` void testReadCurrentLockFile_missingEtag_throwsHoodieLockException() { - StorageLockData data = new StorageLockData(false, 1700000000000L, "testOwner"); - byte[] json = StorageLockFile.toByteArray(data); BlobDownloadContentResponse response = mock(BlobDownloadContentResponse.class); when(response.getHeaders()).thenReturn(null); when(mockBlobClient.downloadContentWithResponse(isNull(), isNull(), isNull(), eq(Context.NONE))).thenReturn(response);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@hudi-azure/src/test/java/org/apache/hudi/azure/transaction/lock/TestAzureStorageLockClient.java` around lines 264 - 276, In testReadCurrentLockFile_missingEtag_throwsHoodieLockException (class TestAzureStorageLockClient) remove the unused local variables StorageLockData data and byte[] json since the test triggers the exception before the response body is used; keep the mocked BlobDownloadContentResponse and existing when(...) stubbing and assertions unchanged so the test still validates the missing ETag behavior.
278-290: Remove unused variables in test.Same as above -
dataandjsonare unused.♻️ Proposed cleanup
`@Test` void testReadCurrentLockFile_emptyEtag_throwsHoodieLockException() { - StorageLockData data = new StorageLockData(false, 1700000000000L, "testOwner"); - byte[] json = StorageLockFile.toByteArray(data); BlobDownloadContentResponse response = mock(BlobDownloadContentResponse.class); when(response.getHeaders()).thenReturn(new HttpHeaders().set("ETag", "")); when(mockBlobClient.downloadContentWithResponse(isNull(), isNull(), isNull(), eq(Context.NONE))).thenReturn(response);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@hudi-azure/src/test/java/org/apache/hudi/azure/transaction/lock/TestAzureStorageLockClient.java` around lines 278 - 290, In the test method testReadCurrentLockFile_emptyEtag_throwsHoodieLockException remove the unused local variables StorageLockData data and byte[] json (they are created but never used) so the test only sets up the mocked BlobDownloadContentResponse and asserts the HoodieLockException; delete the declarations of data and json to clean up the test and keep the rest of the setup (mocking response.getHeaders and mockBlobClient.downloadContentWithResponse) and assertions unchanged.hudi-azure/src/test/java/org/apache/hudi/azure/transaction/lock/TestAzureStorageLockClientUriParsing.java (1)
25-91: Good coverage of URI parsing happy paths.The tests thoroughly cover all supported schemes. Consider adding negative test cases for error handling (e.g., missing container, missing path, unsupported scheme) to ensure
parseAzureLocationthrows appropriateIllegalArgumentExceptions.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@hudi-azure/src/test/java/org/apache/hudi/azure/transaction/lock/TestAzureStorageLockClientUriParsing.java` around lines 25 - 91, Add negative unit tests in TestAzureStorageLockClientUriParsing that call AzureStorageLockClient.parseAzureLocation and assert it throws IllegalArgumentException for invalid URIs: (1) missing container (e.g., "https://account.blob.core.windows.net//path"), (2) missing blob path (e.g., "abfs://container@account.dfs.core.windows.net/"), and (3) unsupported scheme (e.g., "ftp://account/container/path"); use assertThrows to verify the exception and give each test a descriptive name like testParseMissingContainerThrows, testParseMissingPathThrows, testParseUnsupportedSchemeThrows so failures point to the specific invalid-case handling in parseAzureLocation.hudi-azure/src/main/java/org/apache/hudi/azure/transaction/lock/AzureStorageLockClient.java (1)
213-237: Consider documenting the asymmetric exception handling for create vs update.On
HttpResponseException(non-BlobStorage), creates fail fast by re-throwing while updates returnUNKNOWN_ERROR. This is intentional per the comment, but adding a brief inline explanation of why this distinction matters would help future maintainers.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@hudi-azure/src/main/java/org/apache/hudi/azure/transaction/lock/AzureStorageLockClient.java` around lines 213 - 237, Add a short inline comment inside tryUpsertLockFile explaining the asymmetric handling of HttpResponseException: when previousLockFile.isPresent() is false (create) we re-throw the HttpResponseException to fail fast because a create failure likely indicates a systemic or permission issue that should not be masked, whereas on updates we return LockUpsertResult.UNKNOWN_ERROR to allow higher-level retry/coordination logic to handle potential transient conflicts; place this comment immediately above the if (!previousLockFile.isPresent()) branch so maintainers can quickly see the rationale for the different behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@hudi-azure/pom.xml`:
- Line 37: The pom's azure.jackson.version property is pinned to vulnerable
2.13.5; update the property azure.jackson.version to a secure release
(preferably 2.18.6 or later) so all Jackson artifacts that inherit this property
(the Jackson dependencies declared under the pom) are upgraded; if you cannot
move off 2.13.x for Azure SDK compatibility, set azure.jackson.version to the
NES patched coordinate 2.13.5-jackson-core-2.13.7 instead; ensure you run a full
build to confirm compatibility after changing the azure.jackson.version
property.
---
Nitpick comments:
In
`@hudi-azure/src/main/java/org/apache/hudi/azure/transaction/lock/AzureStorageLockClient.java`:
- Around line 213-237: Add a short inline comment inside tryUpsertLockFile
explaining the asymmetric handling of HttpResponseException: when
previousLockFile.isPresent() is false (create) we re-throw the
HttpResponseException to fail fast because a create failure likely indicates a
systemic or permission issue that should not be masked, whereas on updates we
return LockUpsertResult.UNKNOWN_ERROR to allow higher-level retry/coordination
logic to handle potential transient conflicts; place this comment immediately
above the if (!previousLockFile.isPresent()) branch so maintainers can quickly
see the rationale for the different behavior.
In
`@hudi-azure/src/test/java/org/apache/hudi/azure/transaction/lock/TestAzureStorageLockClient.java`:
- Around line 264-276: In
testReadCurrentLockFile_missingEtag_throwsHoodieLockException (class
TestAzureStorageLockClient) remove the unused local variables StorageLockData
data and byte[] json since the test triggers the exception before the response
body is used; keep the mocked BlobDownloadContentResponse and existing when(...)
stubbing and assertions unchanged so the test still validates the missing ETag
behavior.
- Around line 278-290: In the test method
testReadCurrentLockFile_emptyEtag_throwsHoodieLockException remove the unused
local variables StorageLockData data and byte[] json (they are created but never
used) so the test only sets up the mocked BlobDownloadContentResponse and
asserts the HoodieLockException; delete the declarations of data and json to
clean up the test and keep the rest of the setup (mocking response.getHeaders
and mockBlobClient.downloadContentWithResponse) and assertions unchanged.
In
`@hudi-azure/src/test/java/org/apache/hudi/azure/transaction/lock/TestAzureStorageLockClientUriParsing.java`:
- Around line 25-91: Add negative unit tests in
TestAzureStorageLockClientUriParsing that call
AzureStorageLockClient.parseAzureLocation and assert it throws
IllegalArgumentException for invalid URIs: (1) missing container (e.g.,
"https://account.blob.core.windows.net//path"), (2) missing blob path (e.g.,
"abfs://container@account.dfs.core.windows.net/"), and (3) unsupported scheme
(e.g., "ftp://account/container/path"); use assertThrows to verify the exception
and give each test a descriptive name like testParseMissingContainerThrows,
testParseMissingPathThrows, testParseUnsupportedSchemeThrows so failures point
to the specific invalid-case handling in parseAzureLocation.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 7b61e873-30be-4385-9d15-fb672d921c73
📒 Files selected for processing (12)
hudi-azure/pom.xmlhudi-azure/src/main/java/org/apache/hudi/azure/credentials/AzureCredentialFactory.javahudi-azure/src/main/java/org/apache/hudi/azure/transaction/lock/AzureStorageLockClient.javahudi-azure/src/main/java/org/apache/hudi/config/AzureStorageLockConfig.javahudi-azure/src/test/java/org/apache/hudi/azure/transaction/lock/ITAzureStorageLockClientAzurite.javahudi-azure/src/test/java/org/apache/hudi/azure/transaction/lock/TestAzureStorageBasedLockProvider.javahudi-azure/src/test/java/org/apache/hudi/azure/transaction/lock/TestAzureStorageLockClient.javahudi-azure/src/test/java/org/apache/hudi/azure/transaction/lock/TestAzureStorageLockClientUriParsing.javahudi-hadoop-common/src/test/java/org/apache/hudi/common/fs/TestStorageSchemes.javahudi-io/src/main/java/org/apache/hudi/storage/StorageSchemes.javapackaging/hudi-azure-bundle/pom.xmlpom.xml
| <azure.storage.blob.version>12.26.0</azure.storage.blob.version> | ||
| <azure.identity.version>1.12.2</azure.identity.version> | ||
| <!-- Keep Jackson consistent for Azure SDK integration tests (Hudi core pins older Jackson versions). --> | ||
| <azure.jackson.version>2.13.5</azure.jackson.version> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Verify vulnerabilities for jackson-core:2.13.5 from OSV
curl -s https://api.osv.dev/v1/query \
-H "Content-Type: application/json" \
-d '{"package":{"ecosystem":"Maven","name":"com.fasterxml.jackson.core:jackson-core"},"version":"2.13.5"}' \
| jq '{vuln_ids: [.vulns[].id], summaries: [.vulns[].summary]}'Repository: yihua/hudi
Length of output: 339
🏁 Script executed:
cat -n hudi-azure/pom.xml | head -150Repository: yihua/hudi
Length of output: 6482
🌐 Web query:
Jackson 2.13 latest patched version CVE GHSA-72hv-8253-57qq
💡 Result:
The official FasterXML Jackson 2.13 branch latest version is 2.13.5 (released around 2023), with no further patches. The GHSA-72hv-8253-57qq vulnerability (Number Length Constraint Bypass in Async Parser, published Feb 26, 2026, affects jackson-core 2.0.0-2.18.5 and others, patched officially in 2.18.6+) is not patched in official 2.13.x releases, as the branch is closed. Third-party patches exist: - HeroDevs NES: jackson-core 2.13.5-jackson-core-2.13.7 (Mar 3, 2026), explicitly patches GHSA-72hv-8253-57qq, available via their Maven registry (https://registry.nes.herodevs.com/maven). - sassoftware/jackson: Custom branch 2.13.5-CVE-2025-52999-sonatype-2022-6438 remediates related issues but not confirmed for this specific GHSA. For official sources, upgrade to Jackson 2.18.6+ is recommended. HeroDevs provides the latest patched 2.13 variant if stuck on 2.13.
Citations:
- 1: https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.13
- 2: https://docs.herodevs.com/jackson/release-notes/jackson-core-2-13
- 3: GHSA-72hv-8253-57qq
- 4: https://docs.herodevs.com/jackson/release-notes/jackson-core
- 5: https://docs.herodevs.com/jackson/additional-info/maven-packages
- 6: http://docs.herodevs.com/jackson/2-13/jackson
Upgrade Jackson from 2.13.5 to address known vulnerabilities (GHSA-72hv-8253-57qq, GHSA-h46c-h94j-95f3).
azure.jackson.version is pinned to 2.13.5, which contains two high-severity DoS vulnerabilities. The Jackson 2.13.x branch is no longer maintained; upgrade to 2.18.6 or later if Azure SDK compatibility permits. If locked on 2.13.x, use HeroDevs NES patched version 2.13.5-jackson-core-2.13.7 (published Mar 3, 2026, which explicitly patches GHSA-72hv-8253-57qq).
Applies to all Jackson artifacts in lines 118–147 that inherit this version.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@hudi-azure/pom.xml` at line 37, The pom's azure.jackson.version property is
pinned to vulnerable 2.13.5; update the property azure.jackson.version to a
secure release (preferably 2.18.6 or later) so all Jackson artifacts that
inherit this property (the Jackson dependencies declared under the pom) are
upgraded; if you cannot move off 2.13.x for Azure SDK compatibility, set
azure.jackson.version to the NES patched coordinate 2.13.5-jackson-core-2.13.7
instead; ensure you run a full build to confirm compatibility after changing the
azure.jackson.version property.
There was a problem hiding this comment.
yihua has reached the 50-review limit for trial accounts. To continue receiving code reviews, upgrade your plan.
2 participants
Mirror of apache#17951 for automated bot review.
Original author: @chrevanthreddy
Base branch: master
Summary by CodeRabbit
New Features
Packaging
Tests