* Fix cycle detection within fibers
We keep a separate depth count per fiber.
Fixes#1752.
* Avoid additional call to Fiber::getCurrent()
Suppresses phpstan errors, as they're false positives.
One of content_type, content_encoding, message_id, user_id, app_id, delivery_mode, priority, timestamp, expiration, type or reply_to, headers.
Co-authored-by: Попов Михаил <popov.mv@betcity.ru>
We introduced the formatter using the incorrect field, which was making GCP not to extract the correct value from the payload.
This uses the field that actually maps to the expected format.
More info: https://cloud.google.com/logging/docs/structured-logging
Instead of using console.log for all log levels, it uses debug, info, warn and error methods depending on the log level.
This makes filtering logs easier in the browser console and highlights error level messages.
Fixes#1678, closes#1685
When we try to create directory we got error and find out that error is to the fact that directory already was created for us.
If that the case we should not throw exception as it's fine now...
If file was deleted after that it's not problem of this funtion.
One of content_type, content_encoding, message_id, user_id, app_id, delivery_mode, priority, timestamp, expiration, type or reply_to, headers.
Co-authored-by: Попов Михаил <popov.mv@betcity.ru>
Google Cloud Logging doesn't show the correct level log when using
JsonFormatter, making observability a bit trickier. This applies minor
tweaks to the default format, allowing log entries to be properly
represented.
There are alternative packages to this but they add fields that aren't
strictly required - also performing `debug_backtrace()` calls that are
usually not desired when in production mode.
This is a backport of https://github.com/Seldaek/monolog/pull/1690
Signed-off-by: Luís Cobucci <lcobucci@gmail.com>
$record['extra']['callType'] will contain current call type: "->" or "::" depending if it was normal or static method call.
Gives possibility to nicely format messages "{$record['extra']['class']}{$record['extra']['callType']}{$record['extra']['function']} ..."
* Handling the maximum length of a Telegram message
The maximum allowed length of a Telegram message - 4096 symbols (https://core.telegram.org/bots/api#message, 'text' field).
Longer messages are not delivered.
Therefore, I implemented splitting too long message into several (with a 1 second delay between sending according to the documentation - https://core.telegram.org/bots/faq#my-bot-is-hitting-limits-how-do-i-avoid-this) as the default behavior.
An additional option that you can enable by truncateLongMessage is to leave one message, but truncate it to the maximum length allowed.
* Changed handling of long messages (default - truncation, delay - optional)
* PSR-12 code formatting