Runtime View

This chapter describes common runtime behaviour of the GDI Node components in specific cases.

Launch

Each component will perform following (on failure, the component will stop with an error exit code):

  1. Gather configuration from configuration file(s), environment-variables, and Vault.
  2. Configure the logging system.
  3. Establish activity monitor (auditing) for tracking background tasks.
  4. Initiate Postgres connection(s) for connection-pooling. (Ping the database.)
  5. Check other critical connections of the component (e.g. Minio, directory access permissions)
  6. Launch the HTTP-listener.

Shutdown

  1. Wait for known background tasks of the local instance to finish.
  2. Shut down the HTTP listener.
  3. Close all client-connections (e.g. Postgres).
  4. Exit with status code 0.

Request Verification

  1. Get sesssion info from the cookie.
    • If missing but session is required, respond with a temporary redirect to the authentication service.
  2. Request session info from node-session.
    • If the session has expired, respond with a temporary redirect to the authentication service.
  3. Establish user context and user activity monitor.
    • This context also contains user’s permissions.
  4. Continue processing the request.
  5. Finalise the user request processing info in activity monitor.
  6. Return HTTP response.

Exception Reporting

  1. Exceptions must be caught and logged at minimum.
  2. Exception with origin and stack-trace should be included in an activity context for audit-logging.
  3. In HTTP responses, the server must respond with HTTP 500 Problem-Details response.
  4. Exceptions/errors are reported in English. The stack-traces must not be revealed to users (except in audit-logs).
  5. If user can do something about the error, the message should include that action in its description. Otherwise, the default action is to contact the customer-support (helpdesk).
  6. In UI, the error needs to be presented to the user (even failed requests when service is unavailable).
  7. Administrative user with special permission needs a clear UI for viewing past exceptions (optionally marking them resolved or unresolved).
  8. Details about an exception:
    • timestamp: when error occurred
    • request: method, path, and parameters,
    • session: ID, username, permissions
    • client: IP-address, browser (User-Agent)
    • component: name, host/pod
    • error:
      • type: client, internal, external
      • message: the main error message
      • details: optionally additional details
      • hint: optional suggestion for the user