Http Status 400

[JoergTiedemann]

While writing to realtimedatabase with following code

 FirebaseJson StatusJson; 
  // erstmal den Zustand wegschreiben
  if (now == (time_t)0)
      StatusJson.set(timePath, String(0));
  else
      StatusJson.set(timePath, String(now));
  // aktuelle Leistungsdaten
  StatusJson.set("LeistungL1", String(leistungsdata.m_AktL1));
  StatusJson.set("LeistungL2", String(leistungsdata.m_AktL2));
  StatusJson.set("LeistungL3", String(leistungsdata.m_AktL3));
  StatusJson.set("GesamtLeistung", String(leistungsdata.m_AktGesamtLeistung));
  if (m_bWerteGelesen)
  {
    StatusJson.set("AktVerbrauch", String(verbrauchsdata.m_AktVerbrauch-verbrauchsdata.m_StartVerbrauch));
    StatusJson.set("AktEinspeisung", String(verbrauchsdata.m_AktEinspeisung-verbrauchsdata.m_StartEinspeisung));
  }
  else
  {
    StatusJson.set("AktVerbrauch", String(0));
    StatusJson.set("AktEinspeisung", String(0));
  }
  // Serial.printf("Firebase  WriteStatus\n");
  DisplayManager.LogText("WrLeis. 2:"+String(ssl_client.connected()));
  Database.update<object_t>(aClient, strSimulPre + "Stromzaehler/AktStatus", object_t(StatusJson.raw()),processData,"WriteFirebaseLeistungsDaten");
  DisplayManager.LogText("WrLeis. 2b");

In processData

void processData(AsyncResult &aResult)
{
    // Exits when no result available when calling from the loop.
    if (!aResult.isResult())
     return;

    if (aResult.isEvent())
    {
        Firebase.printf("Event task: %s, msg: %s, code: %d\n", aResult.uid().c_str(), aResult.eventLog().message().c_str(), aResult.eventLog().code());
    }

    if (aResult.isDebug())
    {
        Firebase.printf("Debug task: %s, msg: %s\n", aResult.uid().c_str(), aResult.debug().c_str());
    }

    if (aResult.isError())
    {
        bGlobalFirebaseError = true;
        Firebase.printf("Error task: %s, msg: %s, code: %d\n", aResult.uid().c_str(), aResult.error().message().c_str(), aResult.error().code());
        FirebaseManager.DebugError(msgFehler,"processData "+aResult.uid()+":"+aResult.error().message());
    }
    //  if (aResult.available())
    //     Firebase.printf("task: %s, payload: %s<<<---\n", aResult.uid().c_str(), aResult.c_str());
}

I get the error message at aResult.error().message
HTTP Status 400

What could be the reason ?

[mobizt]

The string sets to object_t may contain some character that is not allow in RTDB update JSON representation string.

You have to print to check it.

[JoergTiedemann]

Ok thank you for support
I will check this

[JoergTiedemann]

At this write command (I get the http status 400 error at real-time Database.set an also at realtime Database.update command)

  LoggingJson.set("LoggingTimestamp",now);
  aktLogPath = strSimulPre + "Stromzaehler/Leistungslogging/" +String(now);
  DisplayManager.LogText("WrLeis. 3:"+String(ssl_client.connected()));
 // Serial.printf("Firebase  Write Logging\n");
  Database.set<object_t>(aClient, aktLogPath.c_str(), object_t(LoggingJson.raw()),processData,"WriteFirebaseLeistungsLogging");

I get the http status 400 error and the LoggingJson string in the object_t has the following value

{"LeistungL1":"2","LeistungL2":"110","LeistungL3":"41","LeistungGartenhaus":33.61,"LeistungGarage":119.9,"LoggingTimestamp":1783537406}

I can't see any non valid characters

[mobizt]

I cannot reproduce your error in anyway. The JSON you posted is fine and does not make any Firebase Realtime database update error.

I also test with the code you share but it is ok.

The ssl client that sets to AsyncClientClass should not share usage with any other code.

[JoergTiedemann]

yes of course sorry, it was just a question

what i mean is that i got the http status 400 error if i make a lot of write access to the database
in the example in combination with "operation was cancelled" error, code: -118.
In productive system it could be that I have a write intervall of about 20 -30 seconds, but then if intervall is over i've to perform 4-5 write operations directly behind each other (but not more and with the same payload size as in example)
this is just for information for you

[mobizt]

I ran your exact test program on a bare ESP32 DevKit for more than 2 hours and could not get a single error — not even the -118 (operation was cancelled), while you reproduce the HTTP 400 within minutes. Since we now run the same code with the same library versions, the difference is not in the code — it is in the environment the board runs in.

For context: this library is tested across many platforms (STM32, SAMD, RP2040, ESP8266, ESP32) with the same request/connection code — several of them with far less RAM — and this behavior has never appeared on any of them. The request-building logic is platform-independent, so an intermittent malformed request from the library itself would reproduce everywhere, not only on one specific board.

One important thing you haven't mentioned: the hardware setup of the board you ran the test program on.

1. Did you run the test program on a bare DevKit (nothing connected, powered from a good USB port), or on your production board with the peripherals attached?
2. What is connected to the board and on which GPIOs — display, RS485/meter interface, relays? Do any signals use or run near GPIO 6–11 (internal SPI flash pins) or the strapping pins (GPIO 0, 2, 5, 12, 15)?
3. How is the board powered (USB from PC, external 5V/3.3V supply)? Are there any motors, pumps, or switching loads nearby, or long cables to the Garage/Gartenhaus attached to the board?

The reason I ask: a sporadic, self-recovering HTTP 400 can also be caused by interference on the SPI flash bus or an unstable supply. The ESP32 executes code and reads constants from the external SPI flash continuously (unlike STM32/SAMD which use internal flash), and a single glitched read can corrupt one outgoing request — TLS then faithfully encrypts the corrupted bytes, so the server receives and rejects it with 400 — while the next request is fine again. This matches your error pattern exactly and would also explain why it cannot be reproduced on any other board.

Please re-run the test program on a bare DevKit — nothing connected, short USB cable, powered from a PC or a good charger, placed away from the switching loads — and let me know whether the HTTP 400 still appears.

• If it does not appear on the bare board but appears on your production board with the same firmware → the cause is the hardware environment, not the library.
• If it still appears on the bare board → replace the board with a new one (or a board from a different vendor) and test again. The flash chip, the power circuit, or the WiFi front end of that particular board may be marginal.

[JoergTiedemann]

Hi
thank you very much for your excellent supoport and yes you are right.
It has to be an hardware issue !
I run the testprogramm on a bare devkit (same as in productive system an ESP32 Wroom 32D Rev 3.0 Devkit V4) and I got the error after a few minutes.
If I run the testprogramm on a bare devkit from a different vendor (ESP32 Wroom 32D Rev 3.1 Devkit V4) everything is working fine
So ist has to be a hardware issue !
So tank you very much for your support and the update to Version 2.2.13 because after this update the system is much more stable then before.

Two last questions:

1. If the queue is full then I will get "operation was cancelled" error, code: -118 and the task shown in aResult.uid().c_str() is something like "task_7697". But the task-ID I define at the RTDB write operation is "WriteStatus"

Database.set<object_t>(aClient, String("/Simul/TestHeizung/Heizungsmonitor/Brennerstatus").c_str(), object_t(HeaterstatusJson.raw()),processData,"WriteStatus");

Is there any possibility to reference from the task-id in the error callback ("task_7697") to the corresponding RTDB write operation ?

2. To prevent queue full with "operation was cancelled" error, code: -118 it could be a could idea to check the filling level of the que before performing the RTDB write operation.
   For sure I can control the size of the queue with the build flag FIREBASE_ASYNC_QUE_LIMIT but I want to check if the queue gets full before starting the write operation with

Database.set<object_t>(aClient, String("/Simul/TestHeizung/Heizungsmonitor/Brennerstatus").c_str(), object_t(HeaterstatusJson.raw()),processData,"WriteStatus");

Is there any possibility to do that ?

[mobizt]

Great, thanks for confirming the hardware cause.

To answer your two questions:

1) Referencing the -118 error to the write operation

No, the auto-generated uid (e.g. task_7697) cannot be traced back to your task uid. The reason is that when the queue is full, the task is rejected before its slot is created, so your uid ("WriteStatus") was never assigned — the error is reported through a temporary result object with an auto-generated uid.

However, the -118 error callback is fired synchronously inside the Database.set() call itself — it executes before Database.set() returns. So you always know which write operation it belongs to: the one you are currently calling. If you keep a variable with the name of the operation before each write call, you can read it in the callback when code -118 arrives.

2) Checking the queue level before writing

Yes, use taskCount():

if (aClient.taskCount() < 10) // FIREBASE_ASYNC_QUEUE_LIMIT, default 10 on ESP32
{
    Database.set<object_t>(aClient, path, object_t(json.raw()), processData, "WriteStatus");
}

It returns the number of tasks currently in this AsyncClientClass queue (including the authentication task when it is running). If you keep it below the limit, the -118 error will not occur.

Note: the build flag is FIREBASE_ASYNC_QUEUE_LIMIT (not FIREBASE_ASYNC_QUE_LIMIT).

Keep in mind that each task in the queue takes approximately 1 kB of RAM while it is waiting. Increasing FIREBASE_ASYNC_QUEUE_LIMIT or letting the queue stay full increases the memory usage accordingly, so on a RAM-constrained device it is better to keep the queue short and skip/defer the write when taskCount() is high, rather than enlarging the queue.

[JoergTiedemann]

Ok, sounds good
Thank you very very much for your time and help

[mobizt]

The new version 2.2.13 is available, please try.