C++ API

Callbacks and hooks

Session-level configuration hooks for resumption, exceptions, shutdown, reconnect, and panel events.

These methods configure session-level behavior around the websocket lifecycle. They all belong to blaze::session, but this page focuses on the overall model: when callbacks fire, how they interact with connection resumption, and what threading rules matter in user code.

Detailed method pages

This page explains the model. Full per-method reference lives under Session methods -> Callbacks and hooks.

Callbacks run on the library I/O thread

Do not call synchronous blaze::session methods from these callbacks. Inside callback code, continue with async API only, or hand work back to your own thread/executor.

Common rules

  • Register callbacks before connect if you want to observe the whole lifecycle.
  • Passing nullptr or an empty std::function clears the previously registered callback.
  • Registering a new callback replaces the previous one.
  • These methods are local configuration only. They do not return blaze::status and do not perform a network round trip.
  • Once registered, callbacks stay attached to the same blaze::session object until you replace or clear them.

Callback map

MethodRoleFires when
set_session_resumption_enabled(bool)Resumption policy toggleDoes not fire a callback by itself; it enables or disables automatic session resumption after connection loss.
set_exception_callback(...)Exceptional receive-path failure hookLibrary encounters a receive-path failure that becomes an exception, for example invalid protocol/message data.
set_shutdown_callback(...)Connection-end hookCurrent connection lifecycle ends: explicit shutdown, server close, failed resumption, or final connection-loss shutdown.
set_connection_resumed_callback(...)Successful resumption hookAutomatic session resumption succeeds after unexpected connection loss.
set_panel_event_callback(...)Server-event hookServer sends a valid panel-event packet and event subscription is enabled.

Lifecycle model

Register callbacks before connect if you want to observe the whole session lifecycle.

During normal request/response operation, callbacks stay idle unless a relevant lifecycle event happens.

On unexpected connection loss, the library either attempts session resumption or proceeds to shutdown, depending on set_session_resumption_enabled(...).

If resumption succeeds, set_connection_resumed_callback(...) runs. If it fails, set_shutdown_callback(...) runs when the lifecycle ends.

If the library hits an exceptional receive-path failure, set_exception_callback(...) runs and the session then shuts down.

Minimal setup example

Compilation note

This example compiles in the same form from C++14 to C++26.

#include "blazeauth/api/api.hpp"

#include <exception>
#include <iostream>
#include <string>
#include <system_error>

int main() {
  blaze::session session;

  session.set_session_resumption_enabled(true);

  session.set_exception_callback([](std::exception_ptr eptr) {
    if (!eptr) {
      return;
    }

    try {
      std::rethrow_exception(eptr);
    } catch (const std::system_error& e) {
      std::cout << "Exception callback: " << e.code().message() << '\n';
    } catch (const std::exception& e) {
      std::cout << "Exception callback: " << e.what() << '\n';
    }
  });

  session.set_shutdown_callback([](std::error_code ec, blaze::close_message message) {
    std::cout << "Shutdown callback: " << ec.message() << '\n';

    if (message.code != blaze::close_code::none) {
      std::cout << "Close code: " << static_cast<unsigned int>(message.code) << '\n';
    }
    if (!message.reason.empty()) {
      std::cout << "Close reason: " << message.reason << '\n';
    }
  });

  session.set_connection_resumed_callback([]() {
    std::cout << "Session was resumed\n";
  });

  session.set_panel_event_callback([](blaze::panel_event event) {
    std::cout << "Panel event type: " << static_cast<unsigned int>(event.type) << '\n';
  });

  return 0;
}

On this page