Maksim Kaitmazian authored 4 months ago and Maksim Kaitmazian committed 4 months ago

This test is flaky due to vhsard rebalancing, so migrating to global
tables resolves the issue, since we don't use vshard for them. However,
after this migration one of the `pytest.raises` blocks's been failed,
as turned out, because u64::max value cannot be inserted in global tables.
We decided to don't fix this problem in this commit, so this check
was removed from the test and a new issue was added.

New issue: #1216

It fails a lot in CI lately. There are several open tickets:

#779
#1204

test: back to large (default) timeout in test_gitlab_763_no_missing_buckets_after_proc_sharding_failure

Close: #1032

Now panics from plugin code are handled the same way panics from
picodata code, that is they log the backtrace to the tarantool logger
and then abort the process.

Use gitlab schedule to run these jobs every night to reduce
time it takes to complete main pipeline

Introduce new parameters for alter system:
  - vdbe_max_steps
  - vtable_max_rows

Maksim Kaitmazian authored 4 months ago and Maksim Kaitmazian committed 4 months ago

Co-authored-by: Dmitry Rodionov <d.rodionov@picodata.io>

Previously, LuaValue was used for deserializing msgpack data.
It is marked with #[serde(untagged)] attribute, meaning that
the enum is deserializaed by probing each variant in order unless one
succeeds. It turned out, that this can cause unexpected type convertions
due to the order of variants.

For example, msgpack integer value was deserialized into LuaValue::Double,
because this variant comes before LuaValue::Integer and integer values
can be represented as floats.

This commit resolves this issue by configuring LuaValue to be deserialized
as rmpv::Value using #[serde(try_from)] attribute.

Closes #1130