search

invernyx / smartcars-3-bugs

The bug tracker for the smartCARS 3 application
3 stars 0 forks source link

[BUG] - Runaway log causes broken POST data #200

Closed walkerairtrans closed 1 year ago

walkerairtrans commented 1 year ago

Describe the bug

I've had this happen twice with 2 of my pilots -- it seems like the log runs away from something; maybe engine start/stopping over and over or something else. When this happens the log gets so long that it breaks the POST data and cuts off the the end resulting in a failed PIREP submission.

Here is the POST payload -- I capture this for every flight in the beta just before the API does anything.

The Engine 1 was constantly spamming because of some fuel tanks that were not on. This isn't unusual in some planes with bugs. But first time I've seen this actually impact a PIREP.

example-brokenlog.txt

How do you reproduce this bug?

  1. Log a flight with an overly large log
  2. Submit and see if the POST is broke

Expected behavior

Should not cut the POST data because of size/unless we hit a legitimate limit?

Screenshots

No response

Operating system

Windows 11

Community airline

Walker Air Transport

smartCARS Version

0.9.1

Plugins installed

chat, map, flight center, flight tracker, logbook

Additional context

No response

walkerairtrans commented 1 year ago

Had another pilot today with the same issue.

postdata.txt

walkerairtrans commented 1 year ago

Here is another one. postdata2.txt

GenericNerd commented 1 year ago

These are all Microsoft Flight Simulator. Do the pilots have the latest version of FSUIPC 7?

walkerairtrans commented 1 year ago

These are all Microsoft Flight Simulator. Do the pilots have the latest version of FSUIPC 7?

I'm being told that it's version between .19 and .20 -- the pilots said the log entries were the result of hardware issues resulting in the engine spams. It still reverts back to the log being far too big for you that it breaks the JSON payload.

GenericNerd commented 1 year ago

Interesting! I wonder if this is related to #223! Do you think that could be the reason you are seeing this?

If so, 0.3.5 will send the log and event information as base64 encoded strings, which should reduce the amount of variables sent to the API.

walkerairtrans commented 1 year ago

Interesting! I wonder if this is related to #223! Do you think that could be the reason you are seeing this?

If so, 0.3.5 will send the log and event information as base64 encoded strings, which should reduce the amount of variables sent to the API.

That would be it! It's exceeding the load and I think a huge reason is not only the log, but also FlightData array which also includes the log lines. All of that is exceeding the limits and thus breaking the POST.

I like his idea of stringify it and then decode.

GenericNerd commented 1 year ago

Yep! We have base64 encoding on the client and base64 decoded on the server end (only when the API version is above 0.3.5).

This is done on both the log and data array, meaning this issue is actually going to be resolved through an API update as the client is already updated and expecting this change. Thanks for reporting and helping us get to the bottom of it!