Repository navigation
Normalize configurable field sources and status constants - #667
Conversation
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 14 |
| Duplication | 0 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 63a46cb458
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| TransactionFileFieldSources.FileTotalAmount => ApplyFormat(context.FileTotalAmount, field.Format ?? "0.00"), | ||
| _ => throw new InvalidOperationException($"Unsupported field source '{field.Source}'.") | ||
| }; | ||
| var source = field.Source.Trim(); |
There was a problem hiding this comment.
Normalize sources before configuration validation
When a field source contains leading or trailing whitespace, every production configuration path rejects it before this normalization can run: MerchantProcessingOptionsValidator.AreFieldsValid checks the untrimmed field.Source against TransactionFileFieldSources.All, and both startup loading and SaveAsync invoke that validator. Consequently, configurations using values such as " totalAmount " still fail validation despite the new resolver behavior; trim or canonicalize the source during validation as well.
Useful? React with 👍 / 👎.
Summary
conststring members with static read-only properties across configuration and status definitions.Testing