Conversation
PR Summary by QodoSupport SMDG Waterway Calls in CS Vessel Schedules
AI Description
Diagram
High-Level Assessment
Files changed (2)
|
Code Review by Qodo
1. Departure times may miss date filters
|
|
/agentic_review |
| The start date of the period for which schedule information is requested. If the date of any Timestamp (ATA, ETA or PTA) within a TransportCall is on or after (`>=`) the `startDate`, the entire Voyage (import and export Voyage) containing that TransportCall will be included in the result. Matching is performed using the local date at the TransportCall location. | ||
|
|
There was a problem hiding this comment.
1. Departure times may miss date filters 📎 Requirement gap ≡ Correctness
The startDate and endDate descriptions define any Timestamp with an exhaustive-looking list of only ATA, ETA, and PTA, omitting the corresponding departure timestamps. When a waterway call publishes only DEPA, as the contract permits, the filter documentation does not establish whether its actual, estimated, or planned departure date participates in matching.
Agent Prompt
## Issue description
The date-filter descriptions list only arrival timestamps even though a waterway TransportCall may publish only a departure event.
## Fix Focus Areas
- cs/v1/CS_v1.0.4.yaml[722-723]
- cs/v1/CS_v1.0.4.yaml[732-733]
## Recommended Fix
Update both filter descriptions to include `ATD`, `ETD`, and `PTD`, or remove the restrictive parenthetical and state unambiguously that timestamps derived from either `ARRI` or `DEPA` participate in matching.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| - `isCargoOperationalCall` **MUST** be present and **MUST** be set to `false`. | ||
| - `portVisitReference` **MUST** be omitted. | ||
|
|
||
| A TransportCall that does not satisfy these conditions does not conform to this specification. |
There was a problem hiding this comment.
2. Port calls are declared nonconformant 📎 Requirement gap ≡ Correctness
The final sentence in TransportCall.description applies the preceding waterway-only conditions to every TransportCall instead of limiting them to calls represented as waterways. Ordinary port calls intentionally include portVisitReference and may set isCargoOperationalCall to true, so the specification's supported port branch and its own port examples also reach this unconditional conformance check.
Agent Prompt
## Issue description
The conformance sentence applies waterway-specific requirements to every `TransportCall`, unintentionally making supported ordinary port calls appear nonconformant.
## Fix Focus Areas
- cs/v1/CS_v1.0.4.yaml[1140-1146]
## Recommended Fix
Rewrite the final sentence so it applies only to a `TransportCall` identified as representing a waterway location, leaving ordinary port calls outside these waterway-only conditions. For example: “A waterway TransportCall that does not satisfy these conditions does not conform to this specification.”
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
|
Code review by qodo was updated up to the latest commit 5eaa30c |
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Documentation inconsistencies remain in CS_v1.0.4.yaml.
Get a fresh assessment by requesting another Copilot review.
Review effort: Lite
Findings: 1
What changed in this PR
Adds SMDG waterway entry-point support to CS Vessel Schedules.
Changes:
- Documents waterway location and
TransportCallsemantics. - Adds waterway examples and schema updates.
- Generalizes endpoint descriptions beyond ports.
| File | Summary |
|---|---|
cs/v1/README.md |
Documents waterway support and semantics. |
cs/v1/CS_v1.0.4.yaml |
Updates schemas, examples, and endpoint descriptions. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| The filter parameters `startDate` and `endDate` MUST always be used in combination with any of the other available parameters. | ||
|
|
||
| The resulting payload returned in the responses will always include **entire voyage(s) being matched**, unless otherwise specified (see `responseScope` query parameter). This means that even though a filter only matches a single `Port` (`UNLocationCode`) in a `Voyage` or a single `Timestamp` within a `Port` in a `Voyage` - **the entire Voyage matched** is returned. If the `carrierImportVoyageNumber` of the `Port` differs from the `carrierExportVoyageNumber` of the `Port` then the **entire Voyage** for both these Voyage numbers are included. An example of this is when `&UNLocationCode=DEHAM` is used as a filter parameter. In this case **entire Voyages** would be listed where `DEHAM` is a `Port`. | ||
| The resulting payload returned in the responses will always include **entire voyage(s) being matched**, unless otherwise specified (see `responseScope` query parameter). This means that even though a filter only matches a single TransportCall identified by (`UNLocationCode`) in a `Voyage` or a single `Timestamp` within a `Port` in a `Voyage` - **the entire Voyage matched** is returned. If the `carrierImportVoyageNumber` of the `Port` differs from the `carrierExportVoyageNumber` of the `Port` then the **entire Voyage** for both these Voyage numbers are included. An example of this is when `&UNLocationCode=DEHAM` is used as a filter parameter. In this case **entire Voyages** would be listed containing a TransportCall with `UNLocationCode=DEHAM`. |

SD-3385: In Vessel Schedules - add waterways like in OVS