Skip to content

Debugging NOT_AVAILABLE Responses

This guide provides a systematic approach to debugging NOT_AVAILABLE responses within system logs. By following these steps, you will be able to trace the flow of requests, responses, SMS delivery, and other critical events.

Step 1: Identifying the Initial Request

Goal:

Track the initiating request to understand the origin of the process.

  1. Search Query: 

    {app=~"sia-service"} |= `{hashedMsisdn}`
    Replace {hashedMsisdn} with the actual hashed MSISDN value.

  2. Example Query: 

    {app=~"sia-service"} |= `C41B06E60400074A6EB8BC9486DC0BC50268A0D15006ED2EA0C0B1A881A992D6`

  3. Expected Log Output: 

    [INFO ] 2025-11-23 17:47:49.465 [transactionId] [internalID] [threadName]  c.u.s.a.c.v.AuthController:154 - /business/transaction-touch req:BusinessTouchRequestDto... RequestDto{msisdn='hashedMsisdn', ...} DtoBase{requestId='requestId'}

  4. Key Data to Collect:

    • Transaction ID: Tracks the full lifecycle of the incoming request.
    • Request ID: Tracks the request sent from the customer and its response.
    • Start Time: Records the timestamp of when the request was received.

Step 2: Verifying the Specific Request

Part A: Confirm the Response

  1. Search Query: 

    {app=~"sia-service"} |= `{requestId}`
    Replace {requestId} with the request ID from Step 1.

  2. Example Query: 

    {app=~"sia-service"} |= `b9d8a7dd-a4c6-40e0-b6c5-43cb28326972`

  3. Expected Log Output: 

    [INFO ] 2025-11-23 17:48:47.472 [responseTransactionId] [...] c.u.s.a.k.p.MessageProducer:64 - Sent message=[... responseStatus=NOT_AVAILABLE,... requestId=requestId]

  4. Key Data to Collect:

    • End Time: When the response was sent.
    • Response Transaction ID: Tracks the response's direction.
    • Response Type: Should be NOT_AVAILABLE.

Part B: Analyzing the Source of the Response

If the response was NOT_AVAILABLE, identify whether it originated from a timer expiration or another issue.

  1. Search Query: 

    {app=~"sia-service"} |= `{transactionId}`

  2. Example Query: 

    {app=~"sia-service"} |= `060f51f4b389437cf79a170788544387`

  3. Expected Log Output: 

    [INFO ] [...] c.u.s.a.k.c.TimerConsumer:20 - timer alert received: TimerExpiredMessage(payload={status:NOT_AVAILABLE}, messageType=TIMER_EXPIRED)

  4. Key Observation: A TIMER_EXPIRED log entry indicates that no response was received from the expected applet before the timer ended.

Step 3: Verifying SMS Delivery

SMS delivery is asynchronous, so multiple searches are required.

Part A: Confirm Submission to SMSC

  1. Search Query: 

    {app=~"sms-service"} |= `{transactionId}`

  2. Example Query: 

    {app=~"sms-service"} |= `a0637bd8b385c324652d761320998254`

  3. Expected Log Output: 

    [INFO ] [...] c.u.s.s.s.SmscConnectionManager:16 - smsc[...] submitting request SubmitSM: [... seqNo: 1338343369] [... seqNo: 290564297]

  4. Key Data to Collect:

    • Sequence IDs (seqNo): Extract the IDs for tracking the SMS parts (e.g., 1338343369 and 290564297 for a long SMS split into two parts).

Part B: Retrieve SMSC Message IDs

  1. Search Query (for each seqNo): 

    {app=~"sms-service"} |= `{sequenceId}`

  2. Example Query: 

    {app=~"sms-service"} |= `1338343369`

  3. Expected Log Output: 

    [INFO ] [...] Delivery response arrived: {"sequenceId":"1338343369","smscMessageId":"003F833E79"}

  4. Key Data to Collect:

    • SMSC Message IDs: Unique identifiers confirming submission to the carrier.

Part C: Check Delivery Status

  1. Search Query (for each smscMessageId): 

    {app=~"sms-service"} |= `{smscMessageId}`

  2. Example Query: 

    {app=~"sms-service"} |= `003F833E79`

  3. Expected Log Output: 

    [INFO ] [...] Async delivery receipt received DeliverSM: [... stat:DELIVRD ...]

  4. Key Data to Collect:

    • Status (stat): Ensure the status is DELIVRD (delivered).
    • Error Code (err): Typically 000 for successful deliveries.

Step 4: Verifying MO (Mobile Originated) Messages

If the SMS was delivered successfully, check for MO messages, which indicate a user response.

  1. Search Query: 

    {app=~"sms-service"} |= `MO message received` |= `{hashedMsisdn}`

  2. Example Query: 

    {app=~"sms-service"} |= `MO message received` |= `C41B06E60400074A6EB8BC9486DC0BC50268A0D15006ED2EA0C0B1A881A992D6`

  3. Expected Log Output: 

    [INFO ] [...] MO message received DeliverSM: [... shortMessageData: payload]

  4. Key Data to Collect:

    • Arrival Time: When the MO message was received.
    • Payload (shortMessageData): The content of the user response.

Step 5: Analyzing MO Message Processing

Using the MO payload, examine its handling within the system.

  1. Search Query: 

    {app=~"sim-service"} |= `{payload}` |= `{hashedMsisdn}`

  2. Example Query: 

    {app=~"sim-service"} |= `payload` |= `C41B06E60400074A6EB8BC9486DC0BC50268A0D15006ED2EA0C0B1A881A992D6`

  3. Expected Log Output: 

    [INFO ] [...] c.u.s.s.h.MessageHandlerImpl:113 - Processing message payload from address [hashedMsisdn]

  4. Key Points to Verify:

    • Look for related WARNING logs indicating issues (e.g., TransactionId not matched).
    • Collect any acknowledgments or errors, such as NOTIFICATION_ACK.

Conclusion

Analyze the full timeline of events to understand where issues occurred:

  • Send: Outbound SMS (MT) timestamps.
  • Receive: User response (MO message) delays.
  • Errors: Timer expirations or mismatched transaction data.

In this case: - MT SMS sent: 2025-11-23 17:47:49.490 - MO SMS received: 2025-11-23 17:50:29.730 - Delay: 3 minutes, causing a NOT_AVAILABLE response.