Uploaded image for project: 'Subscription Watch'
  1. Subscription Watch
  2. SWATCH-2043

swatch-contracts swallowing exceptions

XMLWordPrintable

      I keep encountering instances of critical failures happening in swatch-contracts, but leaving no evidence of anything even happening in the logs.  This card is kind of a placeholder right now until exact repro steps can be determined.

       

      • POST host/api/swatch-contracts/internal/rpc/partner/contracts would sometimes fail due to ApiExceptions (when calling subscription service, internal subscription service, entitlement service).  No record of it in the logs, but would return error code from the downstream service as part of the http response.

      • if swatch-contracts rejects an http call because of an exception during auth, a 401 returns but no evidence unless you turn on the access logs (you can attach a debugger and put a breakpoint in com.redhat.swatch.contract.security.RhIdentityHeaderAuthenticationMechanism#authenticate to catch it)

      SWATCH_SELF_PSK=placeholder UMB_ENABLED=false QUARKUS_PROFILE=stage ./gradlew :swatch-contracts:quarkusDev

      http :8000/api/swatch-contracts/internal/swagger-ui/ x-rh-swatch-psk:placeholder x-rh-identity:$(echo 'bad' | base64)

      Steps

      • Throw an exception in any of the resources, for example, a null pointer exception when creating entitlement contracts:
      @Override
        @RolesAllowed({"test"})
        public StatusResponse createPartnerEntitlementContract(PartnerEntitlementContract contract)
            throws ProcessingException {
          String s = null;
          s.toString(); // BOOM!
          return service.createPartnerContract(contract);
        }
      
      • Start the swatch contracts service:
      SWATCH_SELF_PSK=placeholder UMB_ENABLED=false RBAC_ENABLED=false ./gradlew :swatch-contracts:quarkusDev
      
      • Try to create an entitlement contract:
      curl -v -X POST   'http://localhost:8000/api/swatch-contracts/internal/rpc/partner/contracts'   -H 'accept: application/json'   -H 'x-rh-swatch-psk: placeholder'   -H 'Content-Type: application/json'   -d '{
        "action": "contract-new",
        "redHatSubscriptionNumber": "123456",
        "currentDimensions":[
          {"dimensionName":"control_plane_0","dimensionValue":"730","expirationDate":"2024-11-29T23:59:59.999Z"},
          {"dimensionName":"four_vcpu_0","dimensionValue":"1460","expirationDate":"2024-11-29T23:59:59.999Z"}
        ],
        "cloudIdentifiers": {
          "awsCustomerId": "EK57ooq39qs",
          "awsCustomerAccountId": "568056954830",
          "productCode": "6n58d3s3qpvk22dgew2gal7w3"
        }
      }'
      

      The CURL command will return:

      *   Trying 127.0.0.1:8000...
      * Connected to localhost (127.0.0.1) port 8000 (#0)
      > POST /api/swatch-contracts/internal/rpc/partner/contracts HTTP/1.1
      > Host: localhost:8000
      > User-Agent: curl/8.0.1
      > accept: application/json
      > x-rh-swatch-psk: placeholder
      > Content-Type: application/json
      > Content-Length: 467
      > 
      < HTTP/1.1 500 Internal Server Error
      < Content-Type: application/json;charset=UTF-8
      < content-length: 121
      < 
      * Connection #0 to host localhost left intact
      {"status":"500","code":"CONTRACTS5000","title":"Cannot invoke \"String.toString()\" because \"s\" is null","detail":null}
      

      But the application log does not have any information about this exception.

      The root cause of this problem is that the DefaultExceptionMapper is capturing the exception to construct the client response, but won't log the exception.

      Acceptance Criteria

      • The DefaultExceptionMapper should print a log for exceptions.

            jcarvaja@redhat.com Jose Carvajal Hilario
            lburnett0 Lindsey Burnett
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: