delhivery / re-bar Goto Github PK

Currently, gopher works in a server client model. Move it a single static page instead.

Currently a major part of "connection mismatch" are return shipments. Filtering out return shipments will help us to understand actual root causes for connection mismatch (until we have a mechanism to track target block in HQ ref: LM-4119 ).

Example: 596233383591, the <C entry despite having a cid is being ignored. The issue arises due to validator failing to set primary scan attribute for custody scans not carrying a cid.

Segment states are currently transient and should be stored to database for retrieval when the same waybill is encountered again.

Custody scans finally expose the situations where both scans happen within milliseconds of each other. At this point consistency of scan order is required to be exposed by EP to generate accurate data.

Develop an application wrapper that launches instances of kinesis reader, solver and rebar and allows for communication between them.

To handle dynamic connection database, its recommended that connections implement a toggle feature allowing for runtime addition/removal of edges.

While costs are cumulative for a single sub-path, for a path consisting of multiple sub-paths due to forking, the sub-path should carry cumulative costs from the source of the fork. This currently bases to 0 everytime.

Some segments are missing pdd values. This should not happen.

Instead of hard coding configuration for data sources, allow users to configure the same via a config file.

no result for st:ACTIVE AND dst:""
Expected result: all shipments that has left DPC/IPC and yet to receive at dc or at DC.

Currently connections that arrive too late lead to FAIL_LATE_ARRIVAL on active/child segment. This leads to the complication of identifying the actual connections that are failing sincce they are only available in the parent connection.

Allow for the application the expose the parent connection as needed.

Separate the mongo reader and writer into frameworks that work independently in their own processes and allow saving User defined models to read from/write to the database.

Please create a dashboard for following use-cases.

1. Center failure.
2. Connection failure.
   Please find detail requirement in https://docs.google.com/document/d/1IXMsMajePifYCfVmrCXp68uMB86-UBElJzFzshZLJ-s/edit#
   section 1.2.3. and 1.2.4.
3. What is avg. stay at a center when there is a failure( i.e. st=FAIL for the segment)?
4. What is avg. stay at a center when there is a success (i.e. st=REACHED for the segment) ?

awb: 1950100706604
rmk: LOCATION_MISMATCH