CMR-11421: Pass the Cmr-Send-Kms-Metadata-Fixer to CMR during writeback - #132
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
📝 WalkthroughWalkthroughCMR writeback requests now send ChangesCMR writeback header
Estimated code review effort: 1 (Trivial) | ~5 minutes Mergeability Score: ⚪ Minimal · up to This PR adds the metadata-fixer header to the CMR writeback path and updates its test and lockfile; no actionable merge-blocking risk remains beyond normal checks and review. Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install failed: dependency version conflict. Check your lock file or package.json. 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. Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #132 +/- ##
=======================================
Coverage 99.73% 99.73%
=======================================
Files 234 234
Lines 6391 6391
Branches 1900 1900
=======================================
Hits 6374 6374
Misses 16 16
Partials 1 1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
npm audit fixing
Overview
What is the feature?
We noticed in some SIT testing that we could occassionaly get into a loop condition where CMR sends a collection to KMS to fix keyword issues KMS will fix those and then ingest to CMR. This is usually fine if all fixes work but, if the service is only able to fix part of the metadata e.g. if some of the keywords can be fixed because they were old keywords that have been moved/renamed, but, some are "garbage" values meaning they have never existed in KMS we cannot resolve those directly but, we will ingest the revision on KMS to fix the ones we can fix. That results in a subsequent call to KMS. There are several things on the KMS side that make this not an infinite loop but, we still want to be able to just stop this cycle from the KMS call.
What is the Solution?
Pass the header in nasa/Common-Metadata-Repository#2484 in the writeback call
What areas of the application does this impact?
CMR writeback for the KMS metadata fixer service
Testing
Reproduction steps
cmr-validate-keywordsfalse flag that a metadata correction event works to fix some of the issues there but, if there are some it cannot resolve e.g. a keyword which has never existed then we don't get a subsequent request back from CMR back into KMSAttachments
NA
Checklist
Summary by CodeRabbit