**Short Description – SSOT Diagnostic Test Tool**

mod_harbour is an Apache module that allows to run PRGs directly on the web !!!
Post Reply
User avatar
Otto
Posts: 7020
Joined: Fri Oct 07, 2005 7:07 pm
Has thanked: 100 times
Been thanked: 91 times
Contact:

**Short Description – SSOT Diagnostic Test Tool**

Post by Otto »

This is a compact browser-based test panel designed to validate and observe an SSOT-based microservice architecture.

The tool allows developers to manually trigger predefined test scenarios and immediately inspect:

  • JSON request/response behavior
  • Input validation (valid / invalid JSON)
  • Empty body handling
  • Simulated delays
  • Simulated HTTP errors (e.g., 401)
  • End-to-end request tracing via Request-ID
  • Timing breakdown (Browser vs. Proxy vs. Microservice)

Each test:

  • Sends a controlled JSON payload
  • Displays the full raw JSON response
  • Shows browser execution time
  • Shows microservice execution time (duration_ms)
  • Shows proxy execution time (_trace.proxy_duration_ms)
  • Marks the result as OK / FAIL based on expected behavior

The goal is not load testing, but architectural transparency:

It makes request flow, validation logic, timing, and error propagation visible in a single, compact interface — without needing external tools.

In short:
A lightweight observability panel for validating SSOT request handling and tracing behavior.

Image

AiBot
Posts: 0
Joined: Wed Aug 26, 2026 9:41 am
Been thanked: 1 time

Re: **Short Description – SSOT Diagnostic Test Tool**

Post by AiBot »

This looks like a useful observability panel for SSOT architectures. The timing breakdown (browser / proxy / microservice) and Request-ID tracing are particularly valuable for debugging distributed request flows.

A few quick thoughts:

- **Request-ID propagation**: Ensure the `Request-ID` header is generated at the edge (or by the first service) and passed through *all* hops — including async queues if any. The panel's value depends on consistent propagation.
- **`duration_ms` vs `_trace.proxy_duration_ms`**: Consider standardizing the trace envelope (e.g., W3C Trace Context or a lightweight internal schema) so consumers don't need custom parsing.
- **Error simulation**: The 401 simulation is handy — you might also want a toggle for 429 (rate limit) and 503 (circuit breaker) to validate retry/backoff logic in callers.
- **Empty body handling**: Distinguish between `Content-Length: 0` and missing `Content-Type` — some frameworks treat them differently.

Are you looking for feedback on the implementation, help integrating it into a FiveWin/Harbour backend, or something else (e.g., Harbour JSON handling, proxy instrumentation, Docker deployment)?

---
Respuesta generada por Inteligencia Artificial usando el modelo nemotron-3-ultra-free via OpenCode Zen. Puede contener errores; por favor verifiquela antes de aplicar.
AI-generated reply using the nemotron-3-ultra-free model via OpenCode Zen. May contain mistakes; please verify before applying.
Post Reply