Protean (BA: RET10) - compliance checks

[sandeepshahi]

Flow 1

/search (inc)

• request to stop push based incremental must be provided for verification

Ques:

• is pull based incremental search supported ?
• while processing concurrent catalog updates, are the timestamps at provider / item level being used for correct versioning?
• is /select being called for every change in cart, with the same transaction_id?
• while processing unsolicited callbacks, are you ensuring that each response has a unique message_id for a specific transaction_id?
• is confirm retry enaled as mentioned in the doc here? validation of cancellation reason codes when initiated by SNP?
• are hyperlocal and intercity fulfillment states being processed correctly as per routing.type of "P2P" or "P2H2P";

provide a demo video with the entire order journey

[sandeepshahi]

@RaviV-Protean

[RaviV-Protean]

Thanks @sandeepshahi for your feedback.

1. Sure we will submit request to stop incremental request.

Answers:

1. Yes it's supported.
2. No, we are not maintaining versioning as of now. Is it mandatory as per protocol (compliance) ?
3. Yes it's being sent with same transaction_id.
4. Yes we have our validation in place for unique message_id.
5. No confirm retry is not enabled yet, I believe its released very recently and it should not be any blocker in logs approval.
6. Yes its being correctly as mentioned in contract based on hyperlocal and intercity

Sure will be sharing demo video by end of the day today.

[RaviV-Protean]

@sandeepshahi Sharing the demo video https://drive.google.com/drive/folders/1JTvXX4PhgjZLnBt6Sebw-0HKlVUzSiqR?usp=sharing

[sandeepshahi]

/search inc (start/stop)

• context/message_id can't be same
• context/timestamp can't be same
• context/bap_uri seems incorrect

Note

• maintaining versioning is required to avoid race conditions while receiving multiple /on_search catalog
• confirm retry flow is also mandatory

@RaviV-Protean

[RaviV-Protean]

@sandeepshahi, PR has been resubmitted with fixes https://github.com/ONDC-Official/v1.2.0-logs/pull/2037

[RaviV-Protean]

1. There was some confusion in maintaining the versioning of the catalog, but as discussed offline, it cleared our doubts and it's already in place. We are sending NACK to each seller if they send a timestamp that is earlier than our search's timestamp. We store our search call, and upon receiving on_search, we compare the transaction_id and timestamp. If any on_search has a timestamp less than the search's timestamp, we send a NACK to them. (Please refer to the diagram below)

2. Acknowledged we will implement confirm retry mechanism.

sequenceDiagram
    participant BA as Buyer App
    participant Seller1
    participant Seller2

    BA ->> Seller1: POST /search
    BA ->> Seller2: POST /search
    Seller1-->>BA: POST /on_search (timestamp: T1)
    Seller2-->>BA: POST /on_search (timestamp: T2)
    BA->>BA: Store catalog from response <br>in DB (timestamp: T_on_search_1)
    BA->>BA: Store catalog from response <br>in DB (timestamp: T_on_search_2)
    BA->>Seller1: POST /search
    BA->>Seller2: POST /search

    Seller1-->>BA: POST /on_search (timestamp: T3)
    Seller2-->>BA: POST/ on_search (timestamp: T4)

    BA->>BA: Retrieve search timestamp <br>from DB (T_on_search_1, T_on_search_2)

    Note over BA: Compare timestamps T3, T4 with<br> T_on_search_1 and T_on_search_2

    alt T3 < T_search
        BA->>Seller1: NACK
    end

    alt T4 < T_search
        BA->>Seller2: NACK
    end

    Note over BA: If timestamp is valid, process further