Behaviour when extending not AVAILABLE session

[jlurien]

Problem description
Current spec do not indicate the expected behaviour when the extension of the duration of a session in status other than AVAILABLE is requested

Expected action
Agree on the expected result, and update spec and tests.

For sessions with qosStatus = REQUESTED, implementation may accept the request and take into account the petition when the session is activated, or return a success without modifying the original duration (ignoring the request), or even return an error indicating that this request is not acceptable in the current state.
For sessions with qosStatus = UNAVAILABLE, implementation may return a success without modifying the duration (ignoring the request), or return an error indicating that this request is not acceptable in the current state.

[maxl2287]

Hi @jlurien,

Thanks for bringing this to our attention.

Regarding the expected behavior when extending the duration of a session in a status other than AVAILABLE, I propose the following approach:

For sessions with qosStatus = REQUESTED
This is because the session is still pending activation, and extending its duration at this point might lead to unexpected behavior or conflicts.

For sessions with qosStatus = UNAVAILABLE
This is because the session is no longer active, and extending its duration would not have any effect.

{
  "status": 409,
  "code": "SESSION_EXTENSION_NOT_ALLOWED",
  "message": "Extending the session duration is not allowed in the current state ({qosStatus}). The session must be in the AVAILABLE state."
}

By returning an error in both cases, we maintain consistency and avoid potential ambiguities.

Wdyt?

cc @hdamker

[hdamker]

@jlurien @maxl2287 Seems that there are no more opinions yet. Do we want to follow the path to return errors if the session is not in state AVAILABLE?

In this case I would propose a small addition in the description of the operation:

Current:
Extend the overall session duration of an active QoS session.
Proposal:
Extend the overall session duration of an active QoS session (with qosStatus = AVAILABLE)

Regarding the error code we can then go with 400 ("Bad Request"), adding the following example within GenericExtendSessionDuration400:

            SessionExtensionNotAllowed:
              description: Session must be in AVAILABLE state to get extended
              value:
                status: 400
                code: QUALITY_ON_DEMAND.SESSION_EXTENSION_NOT_ALLOWED
                message: Extending the session duration is not allowed in the current state ({qosStatus}). The session must be in the AVAILABLE state.

WDYT? Doing it still for 0.11.0? Adding only the description clarification (that would keep the options how to react open) or also the error example? In both option, I can create the PR asap.

[jlurien]

Going for an error makes sense to me, but in this case probably 409, as @maxl2287 suggests, is more suitable than 400 as the problem is with the status of the session in the server. code QUALITY_ON_DEMAND.SESSION_EXTENSION_NOT_ALLOWED is OK

[hdamker]

@jlurien 409 is also ok for me.

[jlurien]

New test scenario for this case is:

    # Errors 409

    @quality_on_demand_extendQosSessionDuration_409.1_session_not_available
    Scenario: Extending duration for session with qosStatus not available
        Given an existing QoS session with qosStatus not "AVAILABLE"
        And the path parameter "sessionId" is set to the value for that QoS session
        And the request body is set to a valid request body
        When the request "extendQosSessionDuration" is sent
        Then the response status code is 409
        And the response header "x-correlator" has same value as the request header "x-correlator"
        And the response header "Content-Type" is "application/json"
        And the response property "$.status" is 409
        And the response property "$.code" is "QUALITY_ON_DEMAND.SESSION_EXTENSION_NOT_ALLOWED"
        And the response property "$.message" contains a user friendly text

already added to #349

[hdamker]

PR #356 created for the spec. With the following new error response schema:

    SessionStatusConflict409:
      description: Conflict
      headers:
        x-correlator:
          $ref: '#/components/headers/x-correlator'
      content:
        application/json:
          schema:
            $ref: "#/components/schemas/ErrorInfo"
          examples:
            SessionExtensionNotAllowed:
              description: Session extension is in conflict with current session status
              value:
                status: 409
                code: QUALITY_ON_DEMAND.SESSION_EXTENSION_NOT_ALLOWED
                message: Extending the session duration is not allowed in the current state ({qosStatus}). The session must be in the AVAILABLE state.

[jlurien]

It's "example" -> "examples"

[hdamker]

It's "example" -> "examples"

Thanks for catching this. Corrected in PR and in above comment.