Removed recursive subview hiding.

Fix for #367.
Motivation
After investigating this and testing on iOS's 8-12 I could not observe that recursive subview actually does anything(except causing flickering on iOS 11 and 12 :).
Bar button items(including those with custom views) are handled by these:
    navigationItem.leftBarButtonItem?.tintColor = navigationItem.leftBarButtonItem?.tintColor?.withAlphaComponent(alpha)
    navigationItem.rightBarButtonItem?.tintColor = navigationItem.rightBarButtonItem?.tintColor?.withAlphaComponent(alpha)
    navigationItem.leftBarButtonItems?.forEach { $0.tintColor = $0.tintColor?.withAlphaComponent(alpha) }
    navigationItem.rightBarButtonItems?.forEach { $0.tintColor = $0.tintColor?.withAlphaComponent(alpha) }
...
    // Hide the left items
    navigationItem.leftBarButtonItem?.customView?.alpha = alpha
    navigationItem.leftBarButtonItems?.forEach { $0.customView?.alpha = alpha }

    // Hide the right items
    navigationItem.rightBarButtonItem?.customView?.alpha = alpha
    navigationItem.rightBarButtonItems?.forEach { $0.customView?.alpha = alpha }

Title and title view handled here:
    navigationItem.titleView?.alpha = alpha
   ...
    if let titleColor = navigationBar.titleTextAttributes?[NSAttributedString.Key.foregroundColor] as? UIColor {
      navigationBar.titleTextAttributes?[NSAttributedString.Key.foregroundColor] = titleColor.withAlphaComponent(alpha)
    } else {
      let blackAlpha = UIColor.black.withAlphaComponent(alpha)
      if navigationBar.titleTextAttributes == nil {
        navigationBar.titleTextAttributes = [NSAttributedString.Key.foregroundColor: blackAlpha]
      } else {
        navigationBar.titleTextAttributes?[NSAttributedString.Key.foregroundColor] = blackAlpha
      }
    }

Any other "tintable" stuff handled here
    navigationBar.tintColor = navigationBar.tintColor.withAlphaComponent(alpha)

It seems that all cases are covered already without the need to traverse navigation bar view hierarchy updating alpha for each of them(which also has it's problems).
Issue with recursive alpha
As the documentation for UIView.alpha states

transparency imparted by that alpha value affects all of the view's contents, including its subviews

Which results in alpha value of a view being multiplied by alpha of its superview(and superview of superview and so on).
In this illustration you can see what I'm trying to describe:

The first square consists of a white view with alpha 0.5 and a black subview with alpha 0.5. Square two and three are just for comparison - the first one is a black view with alpha 0.25, second one - 0.5.
This shows that recursively applying alpha produces result different from desired - in an attempt to set everything to 0.5 - the result ended up looking as if it has alpha of value 0.25. And this is in controlled environment - view hierarchy depth is limited to 2 in this example, this should be more pronounced when nesting is deeper, the alpha of the deepest view should be desired_alpha^depth.
Here's playground with this setup:
RecursiveAlphaPlayground.playground.zip

Hi @evil159
Thanks for pointing that out, I remember this being added in another PR a while ago, as a fix for the issue you mentioned, #257
I'm unable to test it thoroughly now, can you confirm that the flicker is gone and doesn't introduce regressions?


use pathlib for path operations

The function make_directory can be replaced with
pathlib.Path("path/to/directory").mkdir(exist_ok=True)

See https://docs.python.org/3/library/pathlib.html#pathlib.Path.mkdir. Pathlib has lots of useful operations for paths.
https://github.com/p-koo/cipher/blob/bbfaaf454eff4c700a0d6eaec50997a072c2e2ce/cipher/utils.py#L11-L31

This is nice. Would it be worth changing all of the paths (i.e. os.path.join) to pathlib for consistency?

Would it be worth changing all of the paths (i.e. os.path.join) to pathlib for consistency?

I think it's worth it. I can submit a PR for that.


Adding panel model

Description
Moved the panel model over and made changes to mimic the new structure by separating error handling and logic.
Queries
These are all POST for now.

createPanel
getPanel
getPanelsFromPanelSetID

/createPanel
index allows both a string and a number ("0" and 0). Unsure if this is intentional.
/getPanel
Can't seem to run this command. Running this body gives an error
{
    "id": 0
}

<!DOCTYPE html>

    <meta charset="utf-8">
    <title>Error</title>

Cannot GET /getPanel

/getPanelsFromPanelSetID
Will test this when Panel Set is implemented. I think to it's best to keep this PR open if a foreign key is required to test at least one command. That way we won't need to open another one.

It's cause you used GET, it's a POST

"0" vs 0 has no difference as far as I am aware, all the typescript and model says its a number. And getPanel is a POST not a GET.

The query takes a number for the id, so technically it can just be tested by putting a number like 3 in the body, which will fetch all panels with a panel_set_id of 3.

The query takes a number for the id, so technically it can just be tested by putting a number like 3 in the body, which will fetch all panels with a panel_set_id of 3.

That may be the case, but shouldn't you have a validator to verify that a panel_set with that id exists?

It doesn't crash if no such id exists, it just returns an empty array.

It doesn't crash if no such id exists, it just returns an empty array.

I'm referring to the creation of the panel. If we make a Panel with an invalid panel_set_id, the database will be inaccurate, and will cause errors in the front end

ah, I suppose when both of the branches are in that check can be implemented, as I would need to query to get a panel-set


[WIP][NSE-728] Upgrade to Arrow 7.0.0

Will test the changes after https://github.com/oap-project/arrow/pull/83 gets merged.

See targeted arrow branch https://github.com/oap-project/arrow/tree/arrow-7.0.0-oap


Prevent canceling uncancelable generic callbacks

Generic callbacks should not be canceled once they start running. The guarantee provided by ucxx::Worker is that once the function returns it should be safe to destroy the callback and all its associated resources, which becomes invalid if the callback is scheduled for cancellation but it is already running, therefore, it's a requirement to check whether the callback is already executing and block it until it's finished. If the callback never completes this may cause an irrecoverable hang which cannot be dealt with from UCXX since it's impossible to stop a callback from executing once it has started, it's the user's responsibility to guarantee the callback must return. A warning is raised after multiples of 10 attempts have been tried to cancel a callback that is being executed and canceling did not succeed, so that the user is informed of what is happening.
The most notable issue is somewhat frequently observable in CI, where the Python async test test_from_worker_address_multinode would segfault, in particular with larger amount of endpoints. This was observable in those tests more frequently because there's a large amount of endpoints being created simultaneously by multiple processes, putting more pressure in the resources and causing endpoint creation to take several seconds to complete. In those cases the generic callback executing ucp_ep_create would take longer than the default timeout of 3 seconds and in some cases that would be interpreted as the callback timed out, since ucp_ep_create itself took longer than 3 seconds, causing the worker to attempt to cancel the callback while it was still executing. With this change, the callback will still timeout but only if it didn't start executing yet, if ucp_ep_create ends up never returning, this will cause a deadlock in the application but there's no way for UCXX to recover on its own and warnings are raised, although those hypothetical deadlocks have not been observed in local tests so far. Segfaults should not occur in this situation anymore.
Additionally, unit tests for generic callbacks are now included, which previously were a gap in the testing suite.

Thanks @wence- for the review, since you've pre-approved and I'd very much like to see how this will impact upcoming CI runs I'm gonna move ahead and merge this in now. However, there's still the open question in https://github.com/rapidsai/ucxx/pull/303#discussion_r1812411503, I'm happy to address that in a follow-up PR if that is still an appropriate change.

/merge


GH-34051: [C++] GcsFileSystem lazily starts sequential reads

OpenInputFile() returns a io::RandomAccessFile which supports sequential reads as well as random access reads. The previous implementation eagerly started a sequential read, but many applications do not use that aspect of the API. Because GCS has fairly high latency, this can slow down applications that are only going to read data using ReadAt(). This includes applications using Parquet files via PyArrow.
Fixes #34051
What changes are included in this PR?
Change the GcsFileSystem class to lazily start the download used to implement the io::InputFile APIs.
Are these changes tested?
I think so: the existing tests cover the affected functions.
Are there any user-facing changes?
No.

Closes: #34051

The failure in Python / AMD64 Conda Python 3.9 Sphinx & Numpydoc seems unrelated, or at least I cannot figure out how it relates to the changes in this PR.  If the failure was indeed caused by this PR I would appreciate a hint in the right direction.


Migrations: Support x64 assemblies in package manager console commands

This is a sub-issue of #1058.
One idea I had was to try and use a compatible platform (x86 or AnyCPU) if present, and give a nice error message if one isn't available.

Are there any plans when the Entity Framework Commands (Add-Migration, etc.) will be available for x64 Assemblies as well? We are deprecating 32bit builds and it is not nice being forced to continue with 32bit support just because tools don't support 64 bit.
Therefore, as an alternative to the Package Manger Console scripts of Entity Framework Commands, I am using the Microsoft.Data.Entity.Design.MigrationsOperations class in a C# console application in order to generate my migrations. This works quiet well, except that I also have to mimic the behavior of adding the generated files to the csharp project file (using EnvDTE automation for this, which seems to be deprecated with Visual Studio 2015).
Maybe you could enhance the Microsoft.Data.Entity.Design.MigrationsOperations so that it adds the generated files to the project file (and removes in case of Remove-Migration)?
The big advantage I see with this C# console application approach is that we can debug our model builders when being called by the Entity Framework Commands (which is not that easy when running Package Manager Console Scripts).

@vmsgsp Yes, the current plan (for #5334) is to execute commands out-of-process which will enable x64 configurations to work.

@bricelam Will this x64 support also be implemented for Full .NET (EF7, .NET 4.6)? In #5334 there is only the keyword ".NET Core".

Yes

We ditched app domains for processes in #6288. This "just works" now.

@bricelam, I am using EF 6.2 and .NET 4.7. I am executing add-migration in x64. It does not work for me. I think that is expected ?!

Yes, EF6 executes inside the VS process which is 32-bit. EF Core executes out-of-process which enabled us to support 64-bit.

You may be able to make it work by building as AnyCPU (without Prefer 32-bit)


Running with Modelsim generates error in 3.35.0

Running SVUnit with Modelsim Intel FPGA Starter Edition versions 18.1, 19.1, and 21.2 gives the following Modelsim error, and seems to cause many more errors after that.
** Error (suppressible): (vlog-8688) /usr/local/tools/svunit-code/svunit_base/svunit_filter.svh(31): Illegal access to local member new.
        Full name of member: svunit_pkg::filter::new
        Full name of calling scope: svunit_pkg

Here is a more complete picture of the command and errors. This was happening with one of my tests, but I thought I'd run one of the example tests for clarity.
runSVUnit -t client_unit_test.sv -s modelsim
SVUNIT: Output File: ./.__testsuite.sv
SVUNIT: Creating class __testsuite:
SVUNIT: Creating instances for:
SVUNIT:    client_unit_test
SVUNIT: Output File: testrunner.sv
SVUNIT: Creating testrunner testrunner:
SVUNIT: Creating instances for:
SVUNIT:   __testsuite
cd .; vlib work; vlog -l compile.log  -f .svunit.f +define+SVUNIT_VERSION='"SVUnit v3.35.0"' ; vsim -c -lib work -do "run -all; quit" -l run.log testrunner +SVUNIT_FILTER=*
Model Technology ModelSim - Intel FPGA Edition vlog 10.6d Compiler 2018.02 Feb 24 2018
Start time: 15:45:33 on Nov 08,2021
vlog -l compile.log -f .svunit.f "+define+SVUNIT_VERSION="SVUnit v3.35.0""
-- Compiling package junit_xml
-- Compiling package svunit_pkg
-- Importing package junit_xml
** Error (suppressible): (vlog-8688) /usr/local/tools/svunit-code/svunit_base/svunit_filter.svh(31): Illegal access to local member new.
        Full name of member: svunit_pkg::filter::new
        Full name of calling scope: svunit_pkg
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_UNLESS' starting at server_mock.sv(5)
** at server_mock.sv(5): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_UNLESS' starting at server_mock.sv(5)
** at server_mock.sv(5): (vlog-2730) Undefined variable: 'svunit_pkg'.
** Error: (vlog-13069) ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_UNLESS' starting at server_mock.sv(5)
** at server_mock.sv(5): near "::": syntax error, unexpected ::.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_UNLESS' starting at server_mock.sv(5)
** at server_mock.sv(5): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_UNLESS' starting at server_mock.sv(5)
** at server_mock.sv(5): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_UNLESS' starting at server_mock.sv(6)
** at server_mock.sv(6): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_UNLESS' starting at server_mock.sv(6)
** at server_mock.sv(6): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_UNLESS' starting at server_mock.sv(6)
** at server_mock.sv(6): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_IF' starting at server_mock.sv(10)
** at server_mock.sv(10): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_IF' starting at server_mock.sv(10)
** at server_mock.sv(10): (vlog-2730) Undefined variable: 'svunit_pkg'.
** Error: (vlog-13069) ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_IF' starting at server_mock.sv(10)
** at server_mock.sv(10): near "::": syntax error, unexpected ::.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_IF' starting at server_mock.sv(10)
** at server_mock.sv(10): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_IF' starting at server_mock.sv(10)
** at server_mock.sv(10): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_IF' starting at server_mock.sv(17)
** at server_mock.sv(17): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_IF' starting at server_mock.sv(17)
** at server_mock.sv(17): (vlog-2730) Undefined variable: 'svunit_pkg'.
** Error: (vlog-13069) ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_IF' starting at server_mock.sv(17)
** at server_mock.sv(17): near "::": syntax error, unexpected ::.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_IF' starting at server_mock.sv(17)
** at server_mock.sv(17): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_IF' starting at server_mock.sv(17)
** at server_mock.sv(17): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: /home/hschroeder/mock/./client_unit_test.sv(11): Illegal use of 'automatic' for variable declaration (name).
** Error: /home/hschroeder/mock/./client_unit_test.sv(12): Illegal declaration after the statement near line '8'.  Declarations must precede statements.  Look for stray semicolons.
** Error: /home/hschroeder/mock/./client_unit_test.sv(16): (vlog-2730) Undefined variable: 'svunit_ut'.
** Error: /home/hschroeder/mock/./client_unit_test.sv(16): Illegal use of 'automatic' for variable declaration (svunit_ut).
** Error: /home/hschroeder/mock/./client_unit_test.sv(16): Verilog Compiler exiting
End time: 15:45:33 on Nov 08,2021, Elapsed time: 0:00:00
Errors: 24, Warnings: 0
Reading pref.tcl

# 10.6d

# vsim -c -lib work -do "run -all; quit" -l run.log testrunner "+SVUNIT_FILTER=*"
# Start time: 15:45:34 on Nov 08,2021
# ** Error: (vsim-3170) Could not find 'testrunner'.
#         Searched libraries:
#             /home/hschroeder/mock/work
# Error loading design
Error loading design
# End time: 15:45:34 on Nov 08,2021, Elapsed time: 0:00:00
# Errors: 1, Warnings: 0

Changing line 37 in svunit_filter.sv from local function new(); to function new(); fixes the problem, but I of course don't have a complete picture of the SVUnit source code, so I thought I'd submit an issue. 3.34.0 is fine, the problems start in some commit after that. Thanks!

The idea was to make the filter a singleton, this is why the constructor is local. This is legal code, but it seems that this ModelSim version doesn't support it. Is this a very old version of ModelSim? I read up a bit and saw that it's supposed to be superseded.

I saw that in 21.3 it was superseded by Questa - Intel FPGA Edition. Did you get a chance to try it out?

Thank you so much for your response! I did get a chance to try out Questa 21.1 today and I get largely the same errors:
runSVUnit -t client_unit_test.sv -s questa
SVUNIT: Output File: ./.__testsuite.sv
SVUNIT: Creating class __testsuite:
SVUNIT: Creating instances for:
SVUNIT:    client_unit_test
SVUNIT: Output File: testrunner.sv
SVUNIT: Creating testrunner testrunner:
SVUNIT: Creating instances for:
SVUNIT:   __testsuite
cd .; vlib work; vlog -l compile.log  -f .svunit.f +define+SVUNIT_VERSION='"SVUnit unreleased"' ; vsim -c -lib work -do "run -all; quit" -l run.log testrunner +SVUNIT_FILTER=*
Questa Intel Starter FPGA Edition-64 vlog 2021.2 Compiler 2021.04 Apr 13 2021
Start time: 10:29:35 on Nov 11,2021
vlog -l compile.log -f .svunit.f "+define+SVUNIT_VERSION="SVUnit unreleased""
-- Compiling package junit_xml
-- Compiling package svunit_pkg
-- Importing package junit_xml
** Error (suppressible): (vlog-8688) /usr/local/tools/svunit-code/svunit_base/svunit_filter.svh(31): Illegal access to local member new.
        Full name of member: svunit_pkg::filter::new
        Full name of calling scope: svunit_pkg
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_UNLESS' starting at server_mock.sv(5)
** at server_mock.sv(5): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_UNLESS' starting at server_mock.sv(5)
** at server_mock.sv(5): (vlog-2730) Undefined variable: 'svunit_pkg'.
** Error: (vlog-13069) ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_UNLESS' starting at server_mock.sv(5)
** at server_mock.sv(5): near "::": syntax error, unexpected ::.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_UNLESS' starting at server_mock.sv(5)
** at server_mock.sv(5): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_UNLESS' starting at server_mock.sv(5)
** at server_mock.sv(5): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_UNLESS' starting at server_mock.sv(6)
** at server_mock.sv(6): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_UNLESS' starting at server_mock.sv(6)
** at server_mock.sv(6): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_UNLESS' starting at server_mock.sv(6)
** at server_mock.sv(6): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_IF' starting at server_mock.sv(10)
** at server_mock.sv(10): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_IF' starting at server_mock.sv(10)
** at server_mock.sv(10): (vlog-2730) Undefined variable: 'svunit_pkg'.
** Error: (vlog-13069) ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_IF' starting at server_mock.sv(10)
** at server_mock.sv(10): near "::": syntax error, unexpected ::.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_IF' starting at server_mock.sv(10)
** at server_mock.sv(10): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_IF' starting at server_mock.sv(10)
** at server_mock.sv(10): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_IF' starting at server_mock.sv(17)
** at server_mock.sv(17): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_IF' starting at server_mock.sv(17)
** at server_mock.sv(17): (vlog-2730) Undefined variable: 'svunit_pkg'.
** Error: (vlog-13069) ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_IF' starting at server_mock.sv(17)
** at server_mock.sv(17): near "::": syntax error, unexpected ::.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_IF' starting at server_mock.sv(17)
** at server_mock.sv(17): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: ** while parsing file included at /home/hschroeder/mock/./client_unit_test.sv(5)
** while parsing macro expansion: 'FAIL_IF' starting at server_mock.sv(17)
** at server_mock.sv(17): (vlog-2164) Class or package 'svunit_pkg' not found.
** Error: /home/hschroeder/mock/./client_unit_test.sv(11): Illegal use of 'automatic' for variable declaration (name).
** Error: /home/hschroeder/mock/./client_unit_test.sv(12): Illegal declaration after the statement near line '8'.  Declarations must precede statements.  Look for stray semicolons.
** Error: /home/hschroeder/mock/./client_unit_test.sv(16): (vlog-2730) Undefined variable: 'svunit_ut'.
** Error: /home/hschroeder/mock/./client_unit_test.sv(16): Illegal use of 'automatic' for variable declaration (svunit_ut).
/home/hschroeder/mock/./client_unit_test.sv(16): Verilog Compiler exiting
End time: 10:29:35 on Nov 11,2021, Elapsed time: 0:00:00
Errors: 23, Warnings: 0
Reading pref.tcl

# 2021.2

# vsim -c -lib work -do "run -all; quit" -l run.log testrunner "+SVUNIT_FILTER=*"
# Start time: 10:29:35 on Nov 11,2021
# ** Note: (vsim-3812) Design is being optimized...
# ** Error: (vopt-13130) Failed to find design unit testrunner.
#         Searched libraries:
#             work
# Optimization failed
# ** Note: (vsim-12126) Error and warning message counts have been restored: Errors=1, Warnings=0.
# Error loading design
Error loading design
# End time: 10:29:35 on Nov 11,2021, Elapsed time: 0:00:00
# Errors: 1, Warnings: 0

I'll set up the tools on my machine (at least Questa Starter) and make the code work with them as well.

I haven't manged to install the tools yet, but I did a bling fix. Please try this branch: https://github.com/svunit/svunit/tree/fix-modelsim-intel-fpga-starter-edition-compatibility

This seems to be an issue in "regular" QuestaSim as well.

I did some experimenting on EDAPlayground and I figured out we could keep the singleton. Also a blind fix, but please try this out: https://github.com/svunit/svunit/tree/fix-questasim-compatibility

Both of these are working for me! Thanks!

I installed QuestaSim starter on my machine as well and can confirm this works. This also exposed an issue with filtering and triggered a tirade against SystemVerilog on Twitter, starting with https://twitter.com/TudorTimi/status/1461101240121708547?s=20

Thanks for all your help!!


Ran pyupgrade to upgrade string formatting syntax.

pyupgrade does a number of rewrites but after #14897 and #14902 the only remaining ones for Django are the string rewrites.
printf style formatting is upgraded to str.format(): https://github.com/asottile/pyupgrade/#printf-style-string-formatting
str.format() is then upgraded to an f-string, for simple cases only: https://github.com/asottile/pyupgrade/#f-strings

pyupgrade is intentionally timid and will not create an f-string if it would make the expression longer or if the substitution parameters are sufficiently complicated (as this can decrease readability).

I've looked through the results and I think they'd all pass Django's policy on f strings.

@adamchainz Thanks for this patch :+1: , however we agreed on the mailing list that any bulk updates should be avoided. We also don't prefer any particular formatting:

"String variable interpolation may use %-formatting, f-strings, or str.format() as appropriate, with the goal of maximizing code readability."

Thanks, I forgot to look up that thread. I guess there is a consensus against it then.

We are where we are at the moment regarding the decision not to reformat...
...but when we introduce black, which will reformat string quoting, etc., I think that we could also consider pyupgrade.
It seems a shame to not be able to use such a useful tool to prevent old rot seeping back in. Generally I've always preferred single quotes, but I see the appeal of black to help save time. Equally, I'm not much of a fan of .format(). It's more verbose and slower than %-formatting, but I think f-strings are great and pyupgrade makes this easy. We'd probably want to manually convert those .format() calls that are not converted to f-strings where appropriate.
If both tools were run sequentially we could then add the few commit hashes to the ignored revisions file we were planning to create when we start using black.
Obviously this is my view and we'd need to take it to the mailing list again.
TL;DR: If we're going to be reformatting everything with black, I don't see why we cannot also fix up to use f-strings more widely and, as a result, be able to add pyupgrade to our linting arsenal. In light of the former, I don't see the latter as being any worse/different.

TL;DR: If we're going to be reformatting everything with black, I don't see why we cannot also fix up to use f-strings more widely and, as a result, be able to add pyupgrade to our linting arsenal. In light of the former, I don't see the latter as being any worse/different.

The question is how many linters we will use? flake, isort, black, pyupgrade, pylint etc. I really don't see any benefits of changing %-formatting to the .format(). We drop support for Python versions once per two years I think it is not worth using pyupgrade on daily basis :shrug: . My 2¢.

We drop support for Python versions once per two years I think it is not worth using pyupgrade on daily basis 🤷 . My 2¢.

I think the "upgrade" in the project name makes it confusing. It is possible to use it to prevent new use of old patterns that have previously been "upgraded" using the tool.

@adamchainz We could use --keep-percent-format for now?

I think the "upgrade" in the project name makes it confusing. It is possible to use it to prevent new use of old patterns that have previously been "upgraded" using the tool.

Without changes in the string formatting it suggested two changes related with subprocess.run() and @lru_cache ~30 LOC. IMO calling it once before each feature freeze should be enough.

Thanks all.
TBH I don't think adding another linter here now is worth the price of entry, particularly thinking about new contributors, but also just trees 🌳
The consensus when allowing f-string usage was very much that we were not removing %-fomatting, and avoiding bulk edits for stylistic changes has been mentioned (to avoid) many times.
Any of that is (as ever) open to reevaluation, but I'll close this here on the basis of the status quo.

Thanks for the discussion all.

IMO calling it once before each feature freeze should be enough.

This is a fair call, if you want to add it to the appropriate checklist.


Data base connection issue: PostgreSQL to Auth service

Hi,
Ideally the database services needs to be deployed prior to deploying your micro-services if you are using kubernetes.
If not the services CrashLoopback but restarts always.I found a work around using initcontainers that would do a health check on the db service before deploying them.
You can refer to the deployment yaml files from the link below
https://github.com/airavata-courses/vulcan/tree/develop/kubernetes.


Removing a scheduler interval when a interval action still using it would crash the scheduler

🐞 Bug Report
Affected Services
support-scheduler
Description and Minimal Reproduction
If I remove an interval when an interval action still using it, but leave the action untouched, the scheduler won't start any more next time. I had to manually delete keys associated with the action in the redis database to make the scheduler work again.
Is there a mechanism preventing an interval being removed when it's still used by some actions? something like that you can't remove a profile when it's used by some devices.
🔥 Exception or Error

level=INFO ts=2020-04-27T08:03:21.127215Z app=edgex-support-scheduler source=loader.go:144 name:=scrub-aged-events message="scheduler could not find a interval with interval name : midnight" msg="problem adding support-scheduler interval action"
level=ERROR ts=2020-04-27T08:03:21.127264Z app=edgex-support-scheduler source=init.go:63 msg="Failed to load schedules and events scheduler could not find a interval with interval name : midnight"
level=INFO ts=2020-04-27T08:03:21.12741Z app=edgex-support-scheduler source=database.go:159 msg="Database disconnected"

🌍  Your Environment
Deployment Environment:
go 1.14
EdgeX Version:
master
Anything else relevant?

@novuscy I am unable to recreate this issue. Can you please share more-detailed steps that you carried out when you saw this issue? Thanks.

@novuscy I am unable to recreate this issue. Can you please share more-detailed steps that you carried out when you saw this issue? Thanks.

start a new edgex with core services and scheduler, the default config of scheduler contains midnight interval and 2 actions.
get the ID of the midnight interval.
delete the midnight interval by ID using DELETE method, it returned true and midnight interval was deleted.
restart edgex, message="scheduler could not find a interval with interval name : midnight" msg="problem adding support-scheduler interval action" showed up and scheduler won't connect to the database .

If you delete the midnight interval by NAME, edgex actually prevents you doing that  with an error of "interval still in use by intervalAction(s) name:  midnight", but nothing stops you delete the interval by ID.

same thing happened when I used edgex-cli db purge to clean the database.

And if I update a interval action with a new interval, the old interval seemed somehow still linked to the action, when I try to delete the old interval, an error says that the old one is still in use, and the old interval could not be deleted neither by ID nor by NAME.

@novuscy Your response to my query is much appreciated 👍 This helps - I'll investigate, and will follow up, thanks.

@novuscy I followed the steps, for example:
<IP_ADDRESS>:6379> DEL 892084a1-6972-4dd6-990f-da9bfd8b0d26
(integer) 1
<IP_ADDRESS>:6379> DEL 892084a1-6972-4dd6-990f-da9bfd8b0d26
(integer) 0

But after that, support-scheduler service starts just fine:
level=INFO ts=2020-04-29T14:26:26.986004Z app=edgex-support-scheduler source=loader.go:38 msg="loading intervals, interval actions ..."
level=INFO ts=2020-04-29T14:26:26.986847Z app=edgex-core-data source=init.go:122 msg="Connected to zero Message Bus @ tcp://*:5563 publishing on 'events' topic"
level=INFO ts=2020-04-29T14:26:26.986884Z app=edgex-core-data source=telemetry.go:86 msg="Telemetry starting"
level=INFO ts=2020-04-29T14:26:26.986909Z app=edgex-core-data source=httpserver.go:89 msg="Web server starting (localhost:48080)"
level=INFO ts=2020-04-29T14:26:26.986932Z app=edgex-core-data source=message.go:50 msg="Service dependencies resolved..."
level=INFO ts=2020-04-29T14:26:26.987033Z app=edgex-core-data source=message.go:51 msg="Starting edgex-core-data master "
level=INFO ts=2020-04-29T14:26:26.98706Z app=edgex-core-data source=message.go:55 msg="This is the Core Data Microservice"
level=INFO ts=2020-04-29T14:26:26.987068Z app=edgex-core-data source=message.go:58 msg="Service started in: 3.144534ms"
level=INFO ts=2020-04-29T14:26:26.987924Z app=edgex-support-scheduler source=schedule.go:162 msg="added the interval with id : a1f2280e-67a8-4505-a7a0-1de44341b7f8 into the scheduler queue"
level=INFO ts=2020-04-29T14:26:26.987958Z app=edgex-support-scheduler source=loader.go:130 name=midnight id=a1f2280e-67a8-4505-a7a0-1de44341b7f8 msg="added interval"
level=INFO ts=2020-04-29T14:26:26.988302Z app=edgex-support-scheduler source=schedule.go:315 msg="added the intervalAction with id: 7784c4e4-3e7e-4468-aaec-2afadcb03d73 to interal: midnight into the queue"
level=INFO ts=2020-04-29T14:26:26.988322Z app=edgex-support-scheduler source=loader.go:152 name=scrub-pushed-events id=7784c4e4-3e7e-4468-aaec-2afadcb03d73 msg="added interval action"
level=INFO ts=2020-04-29T14:26:26.988333Z app=edgex-support-scheduler source=schedule.go:315 msg="added the intervalAction with id: cfe0a814-0824-43b5-b3f1-b428a31b8042 to interal: midnight into the queue"
level=INFO ts=2020-04-29T14:26:26.988342Z app=edgex-support-scheduler source=loader.go:152 name=scrub-aged-events id=cfe0a814-0824-43b5-b3f1-b428a31b8042 msg="added interval action"
level=INFO ts=2020-04-29T14:26:26.988352Z app=edgex-support-scheduler source=loader.go:58 msg="finished loading intervals, interval actions"
level=INFO ts=2020-04-29T14:26:26.98837Z app=edgex-support-scheduler source=telemetry.go:86 msg="Telemetry starting"
level=INFO ts=2020-04-29T14:26:26.988443Z app=edgex-support-scheduler source=httpserver.go:89 msg="Web server starting (localhost:48085)"
level=INFO ts=2020-04-29T14:26:26.988466Z app=edgex-support-scheduler source=message.go:50 msg="Service dependencies resolved..."
level=INFO ts=2020-04-29T14:26:26.988544Z app=edgex-support-scheduler source=message.go:51 msg="Starting edgex-support-scheduler master "
level=INFO ts=2020-04-29T14:26:26.988565Z app=edgex-support-scheduler source=message.go:55 msg="This is the Support Scheduler Microservice"
level=INFO ts=2020-04-29T14:26:26.988577Z app=edgex-support-scheduler source=message.go:58 msg="Service started in: 5.421422ms"

Adding some details about getting the ID of the midnight interval, followed by deleting the midnight interval by ID, using DEL method that I mention and outline above:

{
  "id": "c92f450c-9c2d-4832-a7c6-d74dff82ba42",
  "created":<PHONE_NUMBER>983,
  "modified":<PHONE_NUMBER>983,
  "name": "scrub-aged-events",
  "interval": "midnight",
  "target": "core-data",
  "protocol": "http",
  "httpMethod": "DELETE",
  "address": "localhost",
  "port": 48080,
  "path": "/api/v1/event/removeold/age/604800000"
}

And:
{
    "id": "a48fad40-6b87-4b7c-9548-54f074dd3b2d",
    "created":<PHONE_NUMBER>983,
    "modified":<PHONE_NUMBER>983,
    "name": "scrub-pushed-events",
    "interval": "midnight",
    "target": "core-data",
    "protocol": "http",
    "httpMethod": "DELETE",
    "address": "localhost",
    "port": 48080,
    "path": "/api/v1/event/scrub"
}

Thanks for your investigation into this, but I was using REST API to delete the interval ,not the redis cli.

@novuscy I will follow up, thanks.

Circling right back as I was triaging another issue. Yes, I have recreated what you observed:

level=INFO ts=2020-04-30T19:44:23.401166Z app=edgex-support-scheduler source=loader.go:144 name:=scrub-pushed-events message="scheduler could not find a interval with interval name : midnight" msg="problem adding support-scheduler interval action"
level=ERROR ts=2020-04-30T19:44:23.401193Z app=edgex-support-scheduler source=init.go:63 msg="Failed to load schedules and events scheduler could not find a interval with interval name : midnight"

Investigating 👍

The root cause has two parts:

The portion of the application which performs the delete does not first perform a check as to whether the Interval is in use.
The REST handler does not understand and handle errors where the Interval is in use.

While working on a fix, and thanks to input from @AnthonyMBonafide, a possible race condition has been discovered surrounding the area related to this issue. That should be investigated at some point in time.

I have put together a fix for this bug, functionally tested the fix, and am currently working on wrapping up the newly-added unit test cases, following which a PR will be submitted ✅

Referring to the previous comment (above), we decided that there’s a bit much work remaining (unit testing, etc.) for this fix to make it into the Geneva release.
With that in mind, I am documenting here the workaround to this issue, noting that the impact of this bug is low (for anyone who might use the support-scheduler service).
First, a recommendation for the user: Use the REST call to delete by NAME (instead of the REST call to delete scheduler interval by ID)
Providing here the related issue to be aware of: #2554
The problem here (i.e. in Issue-2520) is itself documented in detail in the Description atop the issue.
The underlying problem is that the REST call to delete by ID does not perform a check to ascertain that the interval is currently in use.
Here is the recommended path for the user to take.
At the outset of interacting with the support-scheduler service, first use the REST API to get the entire interval information, and use the interval's NAME, instead of the ID (for deleting the interval).
For example, let's say that the ID happens to have the value 71e5c882-61b8-4d98-a3b7-2aa68d60c5e6.
Then issue this cURL command to get the full interval information:

curl --location --request GET 'http://localhost:48085/api/v1/interval/71e5c882-61b8-4d98-a3b7-2aa68d60c5e6'

For example, let's say we get this response to GET call above:
{
"Timestamps": {
"created":<PHONE_NUMBER>946,
"modified":<PHONE_NUMBER>946
},
"id": "71e5c882-61b8-4d98-a3b7-2aa68d60c5e6",
"name": "midnight",
"start": "20180101T000000",
"frequency": "24h"
}
From this response received, note the interval's name, which is "midnight".
Use "midnight" to delete scheduler interval.
But suppose that deletion of interval (by ID) has already been done.
In that scenario, re-add the interval.


Publish 1.4.6 on NPM

Hey,
Can the newest version shown in the Github releases be uploaded to NPM? On NPM it says 1.4.5 is the latest but in releases on this Github project it shows 1.4.6 is out.

Updated! sorry for the delay


Fix steering controllers library kinematics

A follow-up of #1149 to fix bugs of the steering library, namely

in open-loop mode, zero steering angle was used for IK calculation
discussed in #954 (my fix breaks API of the library, but it had no information about open_loop. I could duplicate the get_commands() method to get_commands_open_loop(), but that would break ABI too?)
wrong wheelspeed was used (traction on steering wheel, instead of other axle was assumed)
Improve odometry of overdetermined measurements. use nonlinear dependency from wheel speed to calculate linear velocity (ideal) vs the old linear average:

This should finally fix #937 #933 and #789

Tests run successfully on iron/humble distro
$ colcon test  --packages-select ackermann_steering_controller bicycle_steering_controller tricycle_steering_controller steering_controllers_library
Starting >>> steering_controllers_library
Finished <<< steering_controllers_library [0.33s]
Starting >>> ackermann_steering_controller
Starting >>> bicycle_steering_controller
Starting >>> tricycle_steering_controller
Finished <<< bicycle_steering_controller [0.93s]
Finished <<< tricycle_steering_controller [0.93s]
Finished <<< ackermann_steering_controller [0.94s]

Summary: 4 packages finished [1.54s]

fe2ba4b0354805523cc42442909902011533f722:
$ colcon test --packages-select steering_controllers_library ackermann_steering_controller bicycle_steering_
controller tricycle_steering_controller
Starting >>> steering_controllers_library
Finished <<< steering_controllers_library [0.38s]
Starting >>> ackermann_steering_controller
Starting >>> bicycle_steering_controller
Starting >>> tricycle_steering_controller
Finished <<< ackermann_steering_controller [0.93s]
Finished <<< bicycle_steering_controller [0.97s]
Finished <<< tricycle_steering_controller [0.96s]

Summary: 4 packages finished [1.76s]


Lowest version of Angular

What is the lowest version of Angukar that is supported? I seem to be getting "Object doesn't support property or method 'map'". I've been trying to hunt this down with no luck. This package works perfect on my Angular 4 app but not my Angular 2. Any ideas?

Found my answer

Re-opening to track "map" issue.

@Azayzel I haven't used .map() anywhere in the source (only in the demo). Can you possibly provide the stack trace of the error. Btw, whats the exact version of Angular 2 that you are using.
Theoretically, this component works with Angular 2.0.0 but after recent changes, I need to test & validate this.

I am using 2.4.3 right now. But, oddly enough it seems to be an issue with ng2-drag-drop. When I exclude that module the program starts up just fine. Closing this and going to look into issue with that package.


It's not really an issue

Everything works exactly as expected! well done!

Please close! Thanks!


Moves liveness and readiness probes files to /tmp

Secure Coding Practices Checklist Link

https://github.com/RedHatInsights/secure-coding-checklist

Secure Coding Checklist

[ ] Input Validation
[ ] Output Encoding
[ ] Authentication and Password Management
[ ] Session Management
[ ] Access Control
[ ] Cryptographic Practices
[ ] Error Handling and Logging
[ ] Data Protection
[ ] Communication Security
[ ] System Configuration
[ ] Database Security
[x] File Management
[ ] Memory Management
[x] General Coding Practices

Codecov Report
Patch coverage: 67.86% and project coverage change: +22.80 :tada:

Comparison is base (209c0c9) 50.14% compared to head (14ac25a) 72.94%.

Additional details and impacted files
@@             Coverage Diff             @@
##           master     #290       +/-   ##
===========================================
+ Coverage   50.14%   72.94%   +22.80%
===========================================
  Files          13       25       +12
  Lines         357      743      +386
===========================================
+ Hits          179      542      +363
- Misses        178      201       +23

Impacted Files
Coverage Δ

clean_expired_records.py
0.00% <0.00%> (ø)

historical_system_profiles/mgmt_views/v0.py
100.00% <ø> (ø)

kafka_listener.py
0.00% <0.00%> (ø)

standalone_flask_server.py
0.00% <ø> (ø)

wsgi.py
0.00% <ø> (ø)

..._system_profiles/notification_service_interface.py
35.00% <35.00%> (ø)

...ical_system_profiles/baseline_service_interface.py
39.13% <39.13%> (ø)

historical_system_profiles/archiver.py
55.05% <54.41%> (+55.05%)
:arrow_up:

historical_system_profiles/config.py
66.66% <60.00%> (-27.28%)
:arrow_down:

...torical_system_profiles/drift_service_interface.py
66.66% <66.66%> (ø)

... and 31 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

looks good to me

I am merging this as it will unblock stage and @SteveHNH 's work.


Organise profiles in folders in the dropdown

Description of the new feature/enhancement
The ability to specify optional folder names for profiles in the profiles dropdown menu.
I am a consultant that works on multiple projects for multiple clients. I typically create a per-client/per-project directory structure in my filesystem and corresponding Terminal profiles rooted to each location. My dropdown list is growing and becoming long-scrolling/unusable. It would be great to have the option to drop down a list of folders, with a rollover/click on each folder revealing a cascading dropdown of profiles.
Proposed technical implementation details (optional)
I see two potential methods of organisation:

Add a new and optional "folder" property in the profile schema. When detected the UI creates the corresponding value as the dropdown entry and groups all profiles sharing that property value below the new entry.

Introduce support for a profile hierarchy along the lines of
profiles/{group-name}/default
profiles/{group-name/list

along with the existing
profiles/default
profiles/list

This would allow profiles below any optionally created {profile-name} to be grouped and displayed in the dropdown while also providing a more intuitive hierarchy for organisation and setting of default values.

Thanks for the suggestion! Please make sure to search for duplicates when filing new issues. This is already being tracked by another issue on our repo - please refer to #1571 for more discussion.
/dup #1571

Thanks for the suggestion! Please make sure to search for duplicates when filing new issues. This is already being tracked by another issue on our repo - please refer to #1571 for more discussion.
/dup #1571


[BUG] We sometimes (incorrectly) get "Error sending. Size of the payload exceeded maximum message size" error when scheduling a message

Describe the bug
We sometimes (I believe incorrectly) get "Error sending. Size of the payload exceeded maximum message size: 256 kb" error when scheduling a message. The message is a copy of a received message, with a single added client property to control the number of times it is re-scheduled. The error message does not make sense to me, as the message was previously sent fine, and the full message body is at most a few hundred bytes (< 1 kb). It is nowhere near the 256 kb limit.
The scheduling (usually) also works after a few retries.
The cause of the exception, however, says "java.lang.IndexOutOfBoundsException: Requested min remaining bytes(155) exceeds remaining(137) in underlying ByteBuffer: java.nio.HeapByteBuffer[pos=636 lim=773 cap=773]". That makes more sense, but I don't know how/why the limit is set to 773 bytes, as that is outside the control of the client code.
Exception or Stack Trace
com.azure.messaging.servicebus.ServiceBusException: Error sending. Size of the payload exceeded maximum message size: 256 kb, errorContext[NAMESPACE: sbn-lydteamet-lydbanken-prod-azeno-1.servicebus.windows.net. ERROR CONTEXT: N/A, PATH: lydbanken-integrasjoner-virtuoso-updater/$management, REFERENCE_ID: lydbanken-integrasjoner-virtuoso-updater-mgmt:receiver, LINK_CREDIT: 0]
	at com.azure.messaging.servicebus.MessagePump.notifyMessage(MessagePump.java:159)
	at com.azure.messaging.servicebus.MessagePump.lambda$handleMessage$3(MessagePump.java:142)
	at com.azure.messaging.servicebus.implementation.instrumentation.ServiceBusReceiverInstrumentation.wrap(ServiceBusReceiverInstrumentation.java:169)
	at com.azure.messaging.servicebus.implementation.instrumentation.ServiceBusReceiverInstrumentation.instrumentProcess(ServiceBusReceiverInstrumentation.java:104)
	at com.azure.messaging.servicebus.MessagePump.handleMessage(MessagePump.java:135)
	at com.azure.messaging.servicebus.MessagePump$RunOnWorker.lambda$apply$0(MessagePump.java:212)
	at reactor.core.publisher.MonoRunnable.call(MonoRunnable.java:73)
	at reactor.core.publisher.MonoRunnable.call(MonoRunnable.java:32)
	at reactor.core.publisher.FluxSubscribeOnCallable$CallableSubscribeOnSubscription.run(FluxSubscribeOnCallable.java:228)
	at reactor.core.scheduler.ImmediateScheduler.schedule(ImmediateScheduler.java:52)
	at reactor.core.publisher.MonoSubscribeOnCallable.subscribe(MonoSubscribeOnCallable.java:52)
	at reactor.core.publisher.Mono.subscribe(Mono.java:4568)
	at reactor.core.publisher.FluxFlatMap$FlatMapMain.onNext(FluxFlatMap.java:430)
	at com.azure.messaging.servicebus.TracingFluxOperator.lambda$hookOnNext$0(TracingFluxOperator.java:67)
	at com.azure.messaging.servicebus.implementation.instrumentation.ServiceBusReceiverInstrumentation.instrumentProcess(ServiceBusReceiverInstrumentation.java:97)
	at com.azure.messaging.servicebus.TracingFluxOperator$1.lambda$subscribe$0(TracingFluxOperator.java:39)
	at com.azure.messaging.servicebus.TracingFluxOperator.hookOnNext(TracingFluxOperator.java:66)
	at reactor.core.publisher.BaseSubscriber.onNext(BaseSubscriber.java:160)
	at reactor.core.publisher.FluxMap$MapSubscriber.onNext(FluxMap.java:122)
	at com.azure.core.amqp.implementation.MessageFlux$RecoverableReactorReceiver.drainLoop(MessageFlux.java:476)
	at com.azure.core.amqp.implementation.MessageFlux$RecoverableReactorReceiver.drain(MessageFlux.java:405)
	at com.azure.core.amqp.implementation.MessageFlux$ReactorReceiverMediator.onNext(MessageFlux.java:878)
	at com.azure.core.amqp.implementation.MessageFlux$ReactorReceiverMediator.onNext(MessageFlux.java:722)
	at reactor.core.publisher.FluxPublishOn$PublishOnSubscriber.runAsync(FluxPublishOn.java:446)
	at reactor.core.publisher.FluxPublishOn$PublishOnSubscriber.run(FluxPublishOn.java:533)
	at reactor.core.scheduler.WorkerTask.call(WorkerTask.java:84)
	at reactor.core.scheduler.WorkerTask.call(WorkerTask.java:37)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)
Caused by: com.azure.messaging.servicebus.ServiceBusException: Error sending. Size of the payload exceeded maximum message size: 256 kb, errorContext[NAMESPACE: sbn-lydteamet-lydbanken-prod-azeno-1.servicebus.windows.net. ERROR CONTEXT: N/A, PATH: lydbanken-integrasjoner-virtuoso-updater/$management, REFERENCE_ID: lydbanken-integrasjoner-virtuoso-updater-mgmt:receiver, LINK_CREDIT: 0]
	at com.azure.messaging.servicebus.ServiceBusSenderAsyncClient.mapError(ServiceBusSenderAsyncClient.java:950)
	at reactor.core.publisher.Mono.lambda$onErrorMap$28(Mono.java:3854)
	at reactor.core.publisher.FluxOnErrorResume$ResumeSubscriber.onError(FluxOnErrorResume.java:94)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.secondError(MonoFlatMap.java:241)
	at reactor.core.publisher.MonoFlatMap$FlatMapInner.onError(MonoFlatMap.java:315)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.secondError(MonoFlatMap.java:241)
	at reactor.core.publisher.MonoFlatMap$FlatMapInner.onError(MonoFlatMap.java:315)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.secondError(MonoFlatMap.java:241)
	at reactor.core.publisher.MonoFlatMap$FlatMapInner.onError(MonoFlatMap.java:315)
	at reactor.core.publisher.MonoNext$NextSubscriber.onError(MonoNext.java:93)
	at reactor.core.publisher.FluxConcatArray$ConcatArraySubscriber.onError(FluxConcatArray.java:186)
	at reactor.core.publisher.MonoFlatMapMany$FlatMapManyMain.onError(MonoFlatMapMany.java:205)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:149)
	at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1865)
	at com.azure.core.amqp.implementation.AmqpChannelProcessor.subscribe(AmqpChannelProcessor.java:283)
	at reactor.core.publisher.Flux.subscribe(Flux.java:8840)
	at reactor.core.publisher.FluxConcatArray$ConcatArraySubscriber.onComplete(FluxConcatArray.java:238)
	at reactor.core.publisher.FluxConcatArray.subscribe(FluxConcatArray.java:79)
	at reactor.core.publisher.MonoFromFluxOperator.subscribe(MonoFromFluxOperator.java:83)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:165)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:158)
	at reactor.core.publisher.FluxMap$MapSubscriber.onNext(FluxMap.java:122)
	at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1865)
	at reactor.core.publisher.MonoCacheInvalidateIf.subscribeOrReturn(MonoCacheInvalidateIf.java:172)
	at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:63)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:165)
	at reactor.core.publisher.Operators$ScalarSubscription.request(Operators.java:2571)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.request(MonoFlatMap.java:194)
	at reactor.core.publisher.MonoFlatMap$FlatMapInner.onSubscribe(MonoFlatMap.java:291)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onSubscribe(MonoFlatMap.java:117)
	at reactor.core.publisher.MonoJust.subscribe(MonoJust.java:55)
	at reactor.core.publisher.MonoDefer.subscribe(MonoDefer.java:53)
	at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:76)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:165)
	at reactor.core.publisher.FluxPeekFuseable$PeekFuseableSubscriber.onNext(FluxPeekFuseable.java:210)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.secondComplete(MonoFlatMap.java:245)
	at reactor.core.publisher.MonoFlatMap$FlatMapInner.onNext(MonoFlatMap.java:305)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.secondComplete(MonoFlatMap.java:245)
	at reactor.core.publisher.MonoFlatMap$FlatMapInner.onNext(MonoFlatMap.java:305)
	at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onNext(FluxMapFuseable.java:129)
	at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onNext(FluxMapFuseable.java:129)
	at reactor.core.publisher.Operators$ScalarSubscription.request(Operators.java:2571)
	at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.request(FluxMapFuseable.java:171)
	at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.request(FluxMapFuseable.java:171)
	at reactor.core.publisher.MonoFlatMap$FlatMapInner.onSubscribe(MonoFlatMap.java:291)
	at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onSubscribe(FluxMapFuseable.java:96)
	at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onSubscribe(FluxMapFuseable.java:96)
	at reactor.core.publisher.MonoJust.subscribe(MonoJust.java:55)
	at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:76)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:165)
	at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onNext(FluxMapFuseable.java:129)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.secondComplete(MonoFlatMap.java:245)
	at reactor.core.publisher.MonoFlatMap$FlatMapInner.onNext(MonoFlatMap.java:305)
	at reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.complete(MonoIgnoreThen.java:294)
	at reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.onNext(MonoIgnoreThen.java:188)
	at reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.subscribeNext(MonoIgnoreThen.java:237)
	at reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.onComplete(MonoIgnoreThen.java:204)
	at reactor.core.publisher.MonoPeekTerminal$MonoTerminalPeekSubscriber.onComplete(MonoPeekTerminal.java:299)
	at reactor.core.publisher.SerializedSubscriber.onComplete(SerializedSubscriber.java:146)
	at reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.onComplete(FluxTimeout.java:235)
	at reactor.core.publisher.MonoNext$NextSubscriber.onComplete(MonoNext.java:102)
	at reactor.core.publisher.MonoNext$NextSubscriber.onNext(MonoNext.java:83)
	at reactor.core.publisher.FluxFilterFuseable$FilterFuseableSubscriber.onNext(FluxFilterFuseable.java:118)
	at reactor.core.publisher.FluxReplay$SizeBoundReplayBuffer.replayNormal(FluxReplay.java:877)
	at reactor.core.publisher.FluxReplay$SizeBoundReplayBuffer.replay(FluxReplay.java:965)
	at reactor.core.publisher.FluxReplay$ReplayInner.request(FluxReplay.java:1711)
	at reactor.core.publisher.FluxFilterFuseable$FilterFuseableSubscriber.request(FluxFilterFuseable.java:191)
	at reactor.core.publisher.MonoNext$NextSubscriber.request(MonoNext.java:108)
	at reactor.core.publisher.Operators$MultiSubscriptionSubscriber.request(Operators.java:2331)
	at reactor.core.publisher.SerializedSubscriber.request(SerializedSubscriber.java:151)
	at reactor.core.publisher.MonoPeekTerminal$MonoTerminalPeekSubscriber.request(MonoPeekTerminal.java:139)
	at reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.onSubscribe(MonoIgnoreThen.java:135)
	at reactor.core.publisher.MonoPeekTerminal$MonoTerminalPeekSubscriber.onSubscribe(MonoPeekTerminal.java:152)
	at reactor.core.publisher.SerializedSubscriber.onSubscribe(SerializedSubscriber.java:65)
	at reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.onSubscribe(FluxTimeout.java:155)
	at reactor.core.publisher.MonoNext$NextSubscriber.onSubscribe(MonoNext.java:70)
	at reactor.core.publisher.FluxFilterFuseable$FilterFuseableSubscriber.onSubscribe(FluxFilterFuseable.java:87)
	at reactor.core.publisher.FluxReplay.subscribeOrReturn(FluxReplay.java:1181)
	at reactor.core.publisher.FluxReplay.subscribe(FluxReplay.java:1153)
	at reactor.core.publisher.FluxAutoConnectFuseable.subscribe(FluxAutoConnectFuseable.java:61)
	at reactor.core.publisher.Mono.subscribe(Mono.java:4568)
	at reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.subscribeNext(MonoIgnoreThen.java:265)
	at reactor.core.publisher.MonoIgnoreThen.subscribe(MonoIgnoreThen.java:51)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:165)
	at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onNext(FluxMapFuseable.java:129)
	at reactor.core.publisher.MonoPeekTerminal$MonoTerminalPeekSubscriber.onNext(MonoPeekTerminal.java:180)
	at reactor.core.publisher.FluxHide$SuppressFuseableSubscriber.onNext(FluxHide.java:137)
	at reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.complete(MonoIgnoreThen.java:294)
	at reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.onNext(MonoIgnoreThen.java:188)
	at reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.subscribeNext(MonoIgnoreThen.java:237)
	at reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.onComplete(MonoIgnoreThen.java:204)
	at reactor.core.publisher.SerializedSubscriber.onComplete(SerializedSubscriber.java:146)
	at reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.onComplete(FluxTimeout.java:235)
	at reactor.core.publisher.MonoNext$NextSubscriber.onComplete(MonoNext.java:102)
	at reactor.core.publisher.MonoNext$NextSubscriber.onNext(MonoNext.java:83)
	at reactor.core.publisher.FluxFilterFuseable$FilterFuseableSubscriber.onNext(FluxFilterFuseable.java:118)
	at reactor.core.publisher.FluxReplay$SizeBoundReplayBuffer.replayNormal(FluxReplay.java:877)
	at reactor.core.publisher.FluxReplay$SizeBoundReplayBuffer.replay(FluxReplay.java:965)
	at reactor.core.publisher.FluxReplay$ReplayInner.request(FluxReplay.java:1711)
	at reactor.core.publisher.FluxFilterFuseable$FilterFuseableSubscriber.request(FluxFilterFuseable.java:191)
	at reactor.core.publisher.MonoNext$NextSubscriber.request(MonoNext.java:108)
	at reactor.core.publisher.Operators$MultiSubscriptionSubscriber.request(Operators.java:2331)
	at reactor.core.publisher.SerializedSubscriber.request(SerializedSubscriber.java:151)
	at reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.onSubscribe(MonoIgnoreThen.java:135)
	at reactor.core.publisher.SerializedSubscriber.onSubscribe(SerializedSubscriber.java:65)
	at reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.onSubscribe(FluxTimeout.java:155)
	at reactor.core.publisher.MonoNext$NextSubscriber.onSubscribe(MonoNext.java:70)
	at reactor.core.publisher.FluxFilterFuseable$FilterFuseableSubscriber.onSubscribe(FluxFilterFuseable.java:87)
	at reactor.core.publisher.FluxReplay.subscribeOrReturn(FluxReplay.java:1181)
	at reactor.core.publisher.FluxReplay.subscribe(FluxReplay.java:1153)
	at reactor.core.publisher.FluxAutoConnectFuseable.subscribe(FluxAutoConnectFuseable.java:61)
	at reactor.core.publisher.Mono.subscribe(Mono.java:4568)
	at reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.subscribeNext(MonoIgnoreThen.java:265)
	at reactor.core.publisher.MonoIgnoreThen.subscribe(MonoIgnoreThen.java:51)
	at reactor.core.publisher.Mono.subscribe(Mono.java:4568)
	at reactor.core.publisher.FluxFlatMap.trySubscribeScalarMap(FluxFlatMap.java:205)
	at reactor.core.publisher.MonoFlatMap.subscribeOrReturn(MonoFlatMap.java:53)
	at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:63)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:165)
	at reactor.core.publisher.FluxMap$MapSubscriber.onNext(FluxMap.java:122)
	at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1865)
	at reactor.core.publisher.MonoCacheInvalidateIf.subscribeOrReturn(MonoCacheInvalidateIf.java:172)
	at reactor.core.publisher.Mono.subscribe(Mono.java:4552)
	at reactor.core.publisher.Mono.block(Mono.java:1806)
	at com.azure.messaging.servicebus.ServiceBusSenderClient.scheduleMessage(ServiceBusSenderClient.java:362)
	at no.nrk.lydbanken.integrasjoner.common.infrastructure.servicebus.ServiceBusQueueConsumer.processMessage(ServiceBusQueueConsumer.java:115)
	at com.azure.messaging.servicebus.MessagePump.notifyMessage(MessagePump.java:157)
	... 31 common frames omitted
	Suppressed: java.lang.Exception: #block terminated with an error
		at reactor.core.publisher.BlockingSingleSubscriber.blockingGet(BlockingSingleSubscriber.java:146)
		at reactor.core.publisher.Mono.block(Mono.java:1807)
		... 34 common frames omitted
Caused by: com.azure.core.amqp.exception.AmqpException: Error sending. Size of the payload exceeded maximum message size: 256 kb, errorContext[NAMESPACE: sbn-lydteamet-lydbanken-prod-azeno-1.servicebus.windows.net. ERROR CONTEXT: N/A, PATH: lydbanken-integrasjoner-virtuoso-updater/$management, REFERENCE_ID: lydbanken-integrasjoner-virtuoso-updater-mgmt:receiver, LINK_CREDIT: 0]
	at com.azure.messaging.servicebus.implementation.ManagementChannel.lambda$schedule$13(ManagementChannel.java:355)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:132)
	... 145 common frames omitted
Caused by: java.nio.BufferOverflowException: null
	at org.apache.qpid.proton.codec.WritableBuffer$ByteBufferWrapper.ensureRemaining(WritableBuffer.java:152)
	at org.apache.qpid.proton.codec.BinaryType.fastWrite(BinaryType.java:75)
	at org.apache.qpid.proton.codec.EncoderImpl.writeBinary(EncoderImpl.java:535)
	at org.apache.qpid.proton.codec.messaging.FastPathDataType.write(FastPathDataType.java:126)
	at org.apache.qpid.proton.codec.messaging.FastPathDataType.write(FastPathDataType.java:36)
	at org.apache.qpid.proton.codec.EncoderImpl.writeObject(EncoderImpl.java:734)
	at org.apache.qpid.proton.message.impl.MessageImpl.encode(MessageImpl.java:740)
	at org.apache.qpid.proton.message.impl.MessageImpl.encode(MessageImpl.java:696)
	at com.azure.messaging.servicebus.implementation.ManagementChannel.lambda$schedule$13(ManagementChannel.java:349)
	... 146 common frames omitted
Caused by: java.lang.IndexOutOfBoundsException: Requested min remaining bytes(155) exceeds remaining(137) in underlying ByteBuffer: java.nio.HeapByteBuffer[pos=636 lim=773 cap=773]
	at org.apache.qpid.proton.codec.WritableBuffer$ByteBufferWrapper.ensureRemaining(WritableBuffer.java:148)
	... 154 common frames omitted

To Reproduce
Steps to reproduce the behavior:
This happens seemingly at random, and only a very small percentage of the times we invoke com.azure.messaging.servicebus.ServiceBusSenderClient.scheduleMessage. I don't have a reproducer that can pinpoint the problem at this point, but the full method where the problem happens is attached below. I believe running the code below either by only using the exception path, or by replacing messageConsumer.consume(message) with something like throw new RuntimeException("Oh no") and running it enough times will show the problem.
As mentioned, the message is (usually) scheduled after a few retries.
Code Snippet
Add the code snippet that causes the issue.
Our processMessage method (passed  on to ServiceBusProcessorClientBuilder.processMessage()) looks like this:
    public void processMessage(ServiceBusReceivedMessageContext serviceBusReceivedMessageContext) {
        ServiceBusReceivedMessage message = serviceBusReceivedMessageContext.getMessage();

        try {
            messageConsumer.consume(message); // Client message processing. Fails with an exception in this case
            serviceBusReceivedMessageContext.complete();
        } catch (Exception exception) {
            int deliveryCount = Optional.ofNullable((Integer) message.getApplicationProperties().get(X_NRK_DELIVERY_COUNT))
                                        .orElse(1);

            if (deliveryCount < 20) {
                int delay = Math.min(1 << (deliveryCount - 1), 120); // Inlined calculation of exponential delay

                ServiceBusMessage retryMessage = new ServiceBusMessage(message);
                retryMessage.getApplicationProperties().put(X_NRK_DELIVERY_COUNT, deliveryCount + 1);
                serviceBusSenderClient.scheduleMessage(retryMessage, OffsetDateTime.now().plusSeconds(delay)); // Where it fails

                serviceBusReceivedMessageContext.complete();
            } else {
                DeadLetterOptions deadLetterOptions = new DeadLetterOptions()
                                                              .setPropertiesToModify(Map.of(X_NRK_DELIVERY_COUNT, 0)) // reset delivery count to prepare for possibility to put message back to queue later
                                                              .setDeadLetterReason(exception.getClass().getName())
                                                              .setDeadLetterErrorDescription(exception.getMessage());

                serviceBusReceivedMessageContext.deadLetter(deadLetterOptions);
            }
        }
    }

    static final String X_NRK_DELIVERY_COUNT = "x-nrk-delivery-count";

Expected behavior
The message should be scheduled without exception.
Screenshots
If applicable, add screenshots to help explain your problem.
Setup (please complete the following information):

OS: n/a, runs in Kubernetes, on AKS
IDE: n/a, runs in Kubernetes, on AKS
Library/Libraries:

com.azure:azure-core:1.51.0
com.azure:azure-core-ampq:2.9.7
com.azure:azure-core-http-netty:1.15.2
com.azure:azure-json:1.2.0
com.azure:azure-messaging-servicebus:7.17.2
com.azure:azure-xml:1.1.0
org.apache.qpid:proton-j:0.34.1

Java version: 21
App Server/Environment: Tomcat
Frameworks: Spring Boot

Additional context
Add any other context about the problem here.
Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[x] Bug Description Added
[x] Repro Steps Added
[x] Setup information Added

Hi @haraldk, could you help with a reference message that ran into this error?
Basically, you would update code to print one of the impacted messages, which I can use to reproduce this. The code change look likes
try {
    serviceBusSenderClient.scheduleMessage(retryMessage, OffsetDateTime.now().plusSeconds(delay));
} catch (ServiceBusException sbe) {
    if (sbe.getCause() != null && sbe.getCause() instanceof AmqpException) {
        final AmqpException amqpException = (AmqpException) sbe.getCause();
        if (amqpException.getErrorCondition() == AmqpErrorCondition.LINK_PAYLOAD_SIZE_EXCEEDED) {
            final Throwable innerCause = amqpException.getCause();
            if (innerCause != null && innerCause instanceof BufferOverflowException) {
                System.out.println(innerCause.getMessage());
                MessagePrinter.print(retryMessage);
            }
        }
    }
    throw sbe;
}

The "MessagePrinter" utility class used above can be found here https://gist.github.com/anuchandy/5b08d59e2ac0528dc58b99541c8765f1

Thanks @anuchandy! I've modified your code slightly to use our logging, but it should otherwise output the same details. Will update the issue with the logged information as soon as possible.

Here's the output of the extra output from a few occurrences extracted from our logs:
Exception message: null

Message {  header=Header{durable=null, priority=4, ttl=1209600000, firstAcquirer=null, deliveryCount=null} properties=Properties{messageId=c344a9cf16bc4926b5bc3426c88b7810, userId=, to='null', subject='https://lydbanken.kubeint.nrk.no/api/archive/record/cab3ff5d-d576-4269-b3ff-5dd576c269de', replyTo='null', correlationId=null, contentType=application/vnd.nrk.lydbanken.archive.v1+json, contentEncoding=null, absoluteExpiryTime=Thu Sep 12 10:45:10 GMT 2024, creationTime=Thu Aug 29 10:45:10 GMT 2024, groupId='null', groupSequence=0, replyToGroupId='null'} application_properties=ApplicationProperties{{x-nrk-delivery-count=2}} message_annotations=MessageAnnotations{{x-opt-scheduled-enqueue-time=Thu Aug 29 10:45:11 GMT 2024}} delivery_annotations=DeliveryAnnotations{{x-opt-transfer-source=SBN-LYDTEAMET-LYDBANKEN-PROD-AZENO-1:TOPIC:LYDBANKEN-ARCHIVE-EVENTS|LYDBANKEN-INTEGRASJONER-VIRTUOSO-UPDATER#24ab2f09-c7bd-4a17-9c22-366989a8048a[5], x-opt-transfer-sn=21384, x-opt-transfer-session=null, x-opt-transfer-hop-count=1, x-opt-transfer-resource=27911146, x-opt-lock-token=15eea98e-c2dc-4b08-8839-05bf80be5555}} body=Data{{"uri":"https://lydbanken.kubeint.nrk.no/api/archive/record/cab3ff5d-d576-4269-b3ff-5dd576c269de","version":3,"changed":"2024-08-29T10:45:09.758605392Z"}} footer=Footer{{}} }

MessageType {  application_properties={x-nrk-delivery-count=java.lang.Integer, } message_annotations={x-opt-scheduled-enqueue-time=java.util.Date, } delivery_annotations={x-opt-transfer-source=java.lang.String, x-opt-transfer-sn=java.lang.Long, x-opt-transfer-session=NAN, x-opt-transfer-hop-count=java.lang.Integer, x-opt-transfer-resource=java.lang.Long, x-opt-lock-token=java.util.UUID, } }

Exception message: null

Message {  header=Header{durable=null, priority=4, ttl=1209600000, firstAcquirer=null, deliveryCount=null} properties=Properties{messageId=0d6c5bb09140495882da6abfa2e9cb5e, userId=, to='null', subject='https://lydbanken.kubeint.nrk.no/api/archive/record/61054037-fff3-449e-8540-37fff3b49e77', replyTo='null', correlationId=null, contentType=application/vnd.nrk.lydbanken.archive.v1+json, contentEncoding=null, absoluteExpiryTime=Thu Sep 12 10:15:22 GMT 2024, creationTime=Thu Aug 29 10:15:22 GMT 2024, groupId='null', groupSequence=0, replyToGroupId='null'} application_properties=ApplicationProperties{{x-nrk-delivery-count=2}} message_annotations=MessageAnnotations{{x-opt-scheduled-enqueue-time=Thu Aug 29 10:15:29 GMT 2024}} delivery_annotations=DeliveryAnnotations{{x-opt-transfer-source=SBN-LYDTEAMET-LYDBANKEN-PROD-AZENO-1:TOPIC:LYDBANKEN-ARCHIVE-EVENTS|LYDBANKEN-INTEGRASJONER-VIRTUOSO-UPDATER#24ab2f09-c7bd-4a17-9c22-366989a8048a[5], x-opt-transfer-sn=21349, x-opt-transfer-session=null, x-opt-transfer-hop-count=1, x-opt-transfer-resource=27911146, x-opt-lock-token=88f9eabc-7452-4168-a0e1-74b5ba3b5b8d}} body=Data{{"uri":"https://lydbanken.kubeint.nrk.no/api/archive/record/61054037-fff3-449e-8540-37fff3b49e77","version":1,"changed":"2024-08-29T10:15:22.092180924Z"}} footer=Footer{{}} }

MessageType {  application_properties={x-nrk-delivery-count=java.lang.Integer, } message_annotations={x-opt-scheduled-enqueue-time=java.util.Date, } delivery_annotations={x-opt-transfer-source=java.lang.String, x-opt-transfer-sn=java.lang.Long, x-opt-transfer-session=NAN, x-opt-transfer-hop-count=java.lang.Integer, x-opt-transfer-resource=java.lang.Long, x-opt-lock-token=java.util.UUID, } }

Exception message: null

Message {  header=Header{durable=null, priority=4, ttl=1209600000, firstAcquirer=null, deliveryCount=null} properties=Properties{messageId=0d6c5bb09140495882da6abfa2e9cb5e, userId=, to='null', subject='https://lydbanken.kubeint.nrk.no/api/archive/record/61054037-fff3-449e-8540-37fff3b49e77', replyTo='null', correlationId=null, contentType=application/vnd.nrk.lydbanken.archive.v1+json, contentEncoding=null, absoluteExpiryTime=Thu Sep 12 10:15:22 GMT 2024, creationTime=Thu Aug 29 10:15:22 GMT 2024, groupId='null', groupSequence=0, replyToGroupId='null'} application_properties=ApplicationProperties{{x-nrk-delivery-count=2}} message_annotations=MessageAnnotations{{x-opt-scheduled-enqueue-time=Thu Aug 29 10:15:29 GMT 2024}} delivery_annotations=DeliveryAnnotations{{x-opt-transfer-source=SBN-LYDTEAMET-LYDBANKEN-PROD-AZENO-1:TOPIC:LYDBANKEN-ARCHIVE-EVENTS|LYDBANKEN-INTEGRASJONER-VIRTUOSO-UPDATER#24ab2f09-c7bd-4a17-9c22-366989a8048a[5], x-opt-transfer-sn=21349, x-opt-transfer-session=null, x-opt-transfer-hop-count=1, x-opt-transfer-resource=27911146, x-opt-lock-token=88f9eabc-7452-4168-a0e1-74b5ba3b5b8d}} body=Data{{"uri":"https://lydbanken.kubeint.nrk.no/api/archive/record/61054037-fff3-449e-8540-37fff3b49e77","version":1,"changed":"2024-08-29T10:15:22.092180924Z"}} footer=Footer{{}} }

MessageType {  application_properties={x-nrk-delivery-count=java.lang.Integer, } message_annotations={x-opt-scheduled-enqueue-time=java.util.Date, } delivery_annotations={x-opt-transfer-source=java.lang.String, x-opt-transfer-sn=java.lang.Long, x-opt-transfer-session=NAN, x-opt-transfer-hop-count=java.lang.Integer, x-opt-transfer-resource=java.lang.Long, x-opt-lock-token=java.util.UUID, } }

Exception message: null

Message {  header=Header{durable=null, priority=4, ttl=1209600000, firstAcquirer=null, deliveryCount=null} properties=Properties{messageId=d6059e2e70304d3a922f71b2d944f462, userId=, to='null', subject='https://lydbanken.kubeint.nrk.no/api/archive/record/658825c8-b0d5-484e-8825-c8b0d5f84ea6', replyTo='null', correlationId=null, contentType=application/vnd.nrk.lydbanken.archive.v1+json, contentEncoding=null, absoluteExpiryTime=Thu Sep 12 10:15:15 GMT 2024, creationTime=Thu Aug 29 10:15:15 GMT 2024, groupId='null', groupSequence=0, replyToGroupId='null'} application_properties=ApplicationProperties{{x-nrk-delivery-count=2}} message_annotations=MessageAnnotations{{x-opt-scheduled-enqueue-time=Thu Aug 29 10:15:17 GMT 2024}} delivery_annotations=DeliveryAnnotations{{x-opt-transfer-source=SBN-LYDTEAMET-LYDBANKEN-PROD-AZENO-1:TOPIC:LYDBANKEN-ARCHIVE-EVENTS|LYDBANKEN-INTEGRASJONER-VIRTUOSO-UPDATER#24ab2f09-c7bd-4a17-9c22-366989a8048a[5], x-opt-transfer-sn=21324, x-opt-transfer-session=null, x-opt-transfer-hop-count=1, x-opt-transfer-resource=27911146, x-opt-lock-token=b4fd5abc-184a-44a9-9bb4-eac3797588b3}} body=Data{{"uri":"https://lydbanken.kubeint.nrk.no/api/archive/record/658825c8-b0d5-484e-8825-c8b0d5f84ea6","version":2,"changed":"2024-08-29T10:15:15.570698376Z"}} footer=Footer{{}} }

MessageType {  application_properties={x-nrk-delivery-count=java.lang.Integer, } message_annotations={x-opt-scheduled-enqueue-time=java.util.Date, } delivery_annotations={x-opt-transfer-source=java.lang.String, x-opt-transfer-sn=java.lang.Long, x-opt-transfer-session=NAN, x-opt-transfer-hop-count=java.lang.Integer, x-opt-transfer-resource=java.lang.Long, x-opt-lock-token=java.util.UUID, } }

The exception message wasn't very helpful in this case, but I hope the extra details can help in finding the issue! 😀

Hi @haraldk, thanks! it looks like the value of the field "Message.Properties.userId" is redacted, possibly a filter in the logging configuration? Could you double check and if so, can we output few new messages again including this field value?

Hi @@haraldk, I can repro this with already shared messages, no need to pull another set of messages (with userId)

hello @haraldk, we have a fix for this https://github.com/Azure/azure-sdk-for-java/pull/41706, thanks for helping with the details and test messages!

Excellent news! I’ll have look, and will test as soon as possible. 😀

The version (7.17.14) with the fix should be available in September release. Closing, now that the changes are merged to the main.


Auth0.js Database / Realm Example - Non-redirect

Dealing with the newer Auth0.js poses some changes to the original example utilizing Auth0's Lock widget.
This example shows the changes necessary in order to handle non-redirect based authentication with Auth0 and GraphCool. It assumes you're using Auth0's database feature either with the default settings or your own custom DB implementation.
I've tested this with my implementation today after speaking with @marktani today implementing a custom enterprise solution - I figured it might be worth posting the changes from the lock version.
Looking forward to some feedback.

Thanks a lot! 🙌


hie hangs in typechecking module step in windows

Using vscode: hie starts as usual until it has to typecheck the module
Relevant log section:

2019-09-13 00:22:36.1391282 [ThreadId 11] - ghcDispatcher:got request 2 with id: Nothing
2019-09-13 00:22:36.1839489 [ThreadId 11] - ghcDispatcher:Processing request as version matches
2019-09-13 00:22:36.2060281 [ThreadId 11] - setTypecheckedModule: file mapping state is: fromList [("D:\\dev\\ws\\haskell\\stack-test\\src\\Main.hs",FileMapping {fmPath = "C:\\TEMP\\ghc-mod4449\\Mai1252.hs", fmTemp = True})]
2019-09-13 00:22:36.2849894 [ThreadId 11] - setTypecheckedModule: before ghc-mod
2019-09-13 00:22:36.6908832 [ThreadId 5] - <--2--{"jsonrpc":"2.0","params":{"uri":"file:///d:/dev/ws/haskell/stack-test/src/Main.hs","diagnostics":[]},"method":"textDocument/publishDiagnostics"}
2019-09-13 00:22:36.6908832 [ThreadId 5] - <--2--{"jsonrpc":"2.0","params":{"id":"0","cancellable":false,"title":"Typechecking Main.hs"},"method":"window/progress/start"}

We can observe that the message "setTypecheckedModule: after ghc-mod" is never emitted
The editor shows the message "Typechecking file" indefinitely
Relevant code fragment in hie-plugin-api:

https://github.com/haskell/haskell-ide-engine/blob/098b1800c16ec1348fe9d380b946ec4ffa884f38/hie-plugin-api/Haskell/Ide/Engine/Ghc.hs#L192-L201

Complete log: hie.log

Ok, so it seems the cause is i am trying to open a stack project with ghc-8.6.4 with hie compiled with ghc-8.6.5, and it already was warning me.
Not sure if it is the expected behaviour cause hie-wrapper falls back to hie-8.6 (that it is ghc-8.6.5) when it has not the exact version.
Anyway this has a clear workaround and a exising warning so imho has not a high priority.


SelectableLazyColumn and Tree keybindings are broken

Keybinding not working, tested on macOs only:

select all | cmd + a
extend selection up/down (shift + arrow up/down)
navigate from leaf to parent node (arrow left when selection is on a leaf)

Fixed by https://github.com/JetBrains/jewel/pull/240


Lambda trigger and DLQ support for SQS extension

Example implementation for #41.
It would be great if there was a way to use this included extension on associated resources instead of having to call it from a shared resource.
I.E.
class MyJob < ApplicationJob
  sqs_queue_with_lambda_trigger(id, {
    dlq: {
      message_retention_period: 1209600
    },
    queue: {
      redrive_policy: {
        max_receive_count: 4
      }
    },
    lambda: {
      function_name: "!GetAtt {namespace}LambdaFunction.Arn"
    }
  })
...

RE: It would be great if there was a way to use this included extension on associated resources instead of having to call it from a shared resource.

Yup, that would be great for #41. Just put this binary support and a blog together: Jets Image Upload Carrierwave Tutorial: Binary Support  Reason I bring it up is that its a good segway from there add support for S3 and SNS events. It'll take some time to tackle it, just haven't gotten to it yet.
This is a good implementation for Shared Resources though. Didn't think to do it this way also. Also, thanks for fixing the AWS::SNS::Topic vs AWS::SNS::Queue 😁
Thinking of a place to put this in the docs structure and then will merge.

Sent a PR with some adjustments to merge into your branch https://github.com/eamsc/jets/pull/1 Overal probably not ready yet but getting closer! Would be nice to add a lightweight spec to this sqs class and also some docs. Take a look at the PR when you get the chance.
Also pushed up this jets-sqs-demo test project to help test the new functionality. Here's the shared resource: line.rb

Released SQS Event Support: http://rubyonjets.com/docs/events-sqs/  Think that addresses this better. Thanks for the ideas though! 👌


Can't accept friend requests

@Override 	public void onFriendRequestReceived(FriendRequestReceivedEvent event) { 		new Thread(() -> { 			try { 				System.out.println("Threaded."); 				Thread.sleep(1000); 				event.getFriendRequest().accept().queue(); 				System.out.println("Accepted."); 			} catch (Exception e) { 			} 		}).start(); 	}
What am I doing wrong? I see "Accepted." in the logs but my discord still thinks I have the request

Well, if you printed anything in the exception catch you'd see that you are receiving a NullPointerException when you call .queue() on .accept()'s RestAction.
I haven't implemented the accept() and ignore() RestActions yet, so until i do, you unfortunately cannot accept friend requests with JDA.

I saw that but I thought it was my code but ok I'll wait, thanks.

I'll be visiting and completing the Client-only parts of JDA after I've released 3.0 out of beta.

Any update @DV8FromTheWorld

Friend requests can only be accepted via the normal Discord client.

Oh, that's too bad.

Client features will remain low-priority until further notice in favor of quality assessment of the core features.
It is to be determined which client features will be available in JDA due to issues with account deverification on some api features.


Fix README usage section syntax errors

Fixed syntax errors in init and main functions that prevented the code from compiling.

Thank you.


onVolumeChangeListener method will be invoked twice when building, i think this method should only  be invoked when I tap the volumn key

Same issue when I launch my app please any solution ?


[WIP] Integrate simphony paraview 0.1.0

This is a work in progress brach to integrate the simphony-paraview plugin.
Note: The test builds will fail until all the registred plugins moved to supporting simphony-common 0.2.0

closing in favor of #60


Chrome gets stuck on removing iframe from DOM after signinSilent timeout passes

Hi all,
I'm fighting with strange issue.
When calling UserManager.signinSilent(..), after frame window timeout passes (I simulate it primitively by raising alert() and waiting more than 10s), IFrameWindow._cleanup() function is called. It tries to remove iframe element from document and releases this._frame so that it can be freed from memory. I don't know why, but in Chrome it then immediatelly gets stuck and keeps using more and more memory (raising by ~2MB/s). Page becomes unresponsive and the only option is to close the tab until it eats whole memory. The iframe seems to be still there, but I'm not sure, as the browser tab becomes unusable, Chrome DevTools doesn't refresh Elements tab, debugger doesn't work, etc..
I'm not able to simulate it in Firefox, though.
After a few days of investigation and struggling, I was able to overcome it by deferred removal of iframe element from DOM after a few seconds, which is not the best solution and I don't understand, what's going on undercover and why is it happening.
Is anybody else experiencing this? Is there perhaps a bug in Chrome related to removing iframe when references to that frame object are being released from memory right before/after?

Any update?

Any update?


Missing Datapoints Eurotronic Spirit Zigbee

Just connected eurotronic spirit zigbee via deconz with conbee 2. all with latest software and firmware versions. the device also appeared in iobroker, but: there's a parameter missing. heatsetpoint is not available, although deconz sends it in the package (the info in the debug log of iobroker is exactly the same as in this posting: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1098#issuecomment-462139654. ) so it should basically be supported from deconz. offset temp is available and the value is controllable. i've already tried to create the state for heatsetpoint manually, but always when i trigger a value, it turns red.
any suggestions, workarounds, time and energy for a bugfix maybe?
i really don't want to return the device, if it would work, it would be the perfect solution for my situation.
ps: just recognized that the on parameter is also not controllable, although its visible. boost, locked, off, displayflipped are also not visible.

I know that and is already planned. Its not a bug, its a feature. The datapoints and its handling has to be added manual for propper function.
If it is really urgent for you, you can send me money so i can give it a higher priority.

I'm glad that it's on your to do list, but honestly, at the moment ican't spend more money. The main reason, why i don't just buy another device with another gateway is a lack of money. So j have to be patient, and witsh you good luck....ps: may i'll send you a coffee next month.
Greetings

Mhmmmm....doesn't seem to be difficult to integrate those states...

If you could do this, you are welcome.

done, works perfectly.
i've created a fork, but it would be very nice if you copy those few changes back into your project, i don't want to maintain this....
https://github.com/ac1dwalk3r/ioBroker.deconz.git
ps: this was my first time writing a code....ok, i just copied a few parts and changed the datatype^^

Nice, but there is something missing. The values for heatsetpoint is in this format 2100, that is the equivalent to 21.00°C. So this has to be calculated into that form for user interaction. Also the object definition is missing "Unit: °C".
Please create a Pull Request, so it is easy for me only hit a button and your changes will be merged.

yeah, i noticed before....i just copied the datapoint "offset", with all the definitions, it was the only working one, and there you also have to type 30 for 3.0
at least it works, thats important, i'll think about the format later...

@Jey-Cee Can you already say when the merge will be done?

Yepp never, because  i have rewritten a lot of the adapter code. This means datapoints for eurotronic are included in the next Version.

Nice! Thank you very much.


Can't find the image on AWS

Hi, it must have been deleted, do you have any other? Or how can I test the project?

Same for me. I can't find the image.

Hello, have you found a way to make the project work with or without the AWS image ?

Still can't find a way of testing out this project. Any updates to the AMI?


Add eager option to watch calls

In order to fix https://github.com/pyviz/param/issues/322 I implemented a scheme by which watch calls would execute in the order the user scheduled them. This meant that if a watch callback triggered another event, that event would not get called until all previous events had been processed.
This fix was important for certain (relatively rare) scenarios and ensured correctness, however it also has the quite annoying side-effect that you cannot define a watch callback which temporarily sets and unsets a parameter that has some side-effect, e.g. when you click a button in panel you might want to disable that button while you perform some computation (e.g. see #350), in this scenario you want param to eagerly execute any callbacks as they are triggered. The distinction here is akin to depth-first vs. breadth-first execution of callbacks.
To control this I've added an eager keyword to watch calls. I'd be happy to rename that to something that reflects the depth- vs. breadth-first distinction. Additionally I'm now also not clear whether the current default of breadth-first execution is more desirable, and would consider changing the default. I think it's a very common usecase particularly in panel to trigger some temporary side-effect in a callback and teaching users about the execution model seems difficult.
Closes https://github.com/pyviz/param/issues/350

[ ] Decide on API and naming
[ ] Decide whether to change the default
[ ] Add tests

It also seems like depth-first execution is what a regular user would naively expect, because naively you wouldn't expect an event queue to handle the bread first case for you.

I don't have an opinions about the name. It's worth working out which scenarios work better in eager=True, and which work better in eager=False, and try to estimate which of those are more common scenarios.  If they are about equally common, I'd say to keep the current default behavior.  If one of the categories is way more common and typical than the other, favor that one.  I don't have a good idea myself which way that falls.

I think depth-first is way more common, wanting some side-effect to take place while you run some callback is very common, e.g. change the style or color of a widget or disable it while it executes is a common usecase. Even in pure param usage you may want a callback to trigger some other side-effect on the same class. Comparing that to the breadth-first case I can't think of many cases where that would occur, you will note for example that I had to draw out a whole diagram for #322 to even visualize and understand the three way interaction where breadth-first execution is important.

What about a busy indicator or progress bar; sounds like easier in depth-first?

What about a busy indicator or progress bar; sounds like easier in depth-first?

If the busy indicator lives on the same class yes. One thing I didn't explain well enough that the depth vs breadth first execution model only matters for events happening on the same object, for everything else it's always depth-first. That inconsistency is, I believe another good reason to go for depth-first.

Ok, sounds good.

Instead of eager (which makes me think of eager versus lazy evaluation) how about queued? By default (currently) it sounds like things go into a queue so queued=False would mean 'eager'.


Only activate if -vv used

Fixes #7.

Fixes #8, not #7, right?
I think it is good in general - messing with user options is not a good idea.  It could be however get activated/used still.
Related: https://github.com/pytest-dev/pytest/issues/5932, https://github.com/pytest-dev/pytest/pull/5933

Well actually ... both :)

So adding -vv that way breaks xdist then somehow?


Networking API helpers

After playing around with several containers and figuring out the basic ins and outs of routing and proxying, I could definitely use some help from lxd itself. Follows some suggestions:

on lxc launch allow selecting a specific ip, istead of getting a random one. i.e. lxc launch ubuntu-daily:16.04 u1 -4 <IP_ADDRESS>
expose hostnames/containernames to containers, so that intercontainer communication is namebased, not ip based.
have the daemon monitor which ports on a container have a listener, i.e. lxc ports nginx would return 80,443 (esp. interesting with the point below)
allow to hook into events i.e. if a

new container is launched and a specific parameter is passed/set, launch a script
a container is started/stopped do something else

Basically anything that would allow me to automate reconfiguring iptables and a proxy container (in my case nginx) routing requests to the correct container would be really helpful.
Should I be suggesting something that was already implemented and I just didnt RTFM well enough, point that out for me, pretty please. You will make my life with lxd more lovable.
p.s.: This ticket is very loosely inspired on how https://github.com/jwilder/nginx-proxy works

Some of that will likely be covered with the new network API we're planning, we'll look at this issue again once that's done.

great! looking forward to the api & thanks for all the work sofar!

Current LXD runs its own dnsmasq process which manages DNS (there are three configurable mode) so that containers can resolve each other rather than rely on IPs. You can also set static IP allocations through the ipv4.address and ipv6.address properties of the nic device now.
Hooking into events can be done to some extent through the /events API though it may not exactly be the most user friendly interface for this. We may consider developing something better, possibly a different class of events which aren't arbitrary strings of text but are typically very much opposed to shelling out to random binaries from LXD itself as it makes for a very random, hard to debug experience and makes things differ between hosts during migration.
For the ports, it's something we could return per-interface in the /state API but not in a way that'd be that useful to you. It would report ports bound for every interface with what IP they're bound for but from the outside you have no way to know what interface is actually exposed and which isn't.
A container can absolutely do:
ip link set eth0 name blah
ip link add type dummy name eth0

At which point things bound to "eth0" are actually container-only (loopback-like) and things bound to "blah" are exposed to the outside.
Anyway, since the bulk of this has been fixed with the network API. I'm closing the issue. Feel free to open feature requests for any feature that you'd still need and we can consider them then.


tensorflow 2.1.0 error

macOS Catalina 10.15.4
PyCharm 2019.3.2 (Community Edition)
I used the most updated tensorflow 2.1.0 to run comes with below error:
module 'tensorflow_core._api.v2.config' has no attribute 'experimental_list_devices'
Then I downgrade to tensorflow 2.0.0 everything is good.

import tensorflow as tf
List available physical devices
physical_devices = tf.config.list_physical_devices()
Print the list of devices
for device in physical_devices:
print(device)

这是来自QQ邮箱的假期自动回复邮件。您好，邮件以收到，我会尽快给您回复。


Is there a way to do sync queries?

The async methods all seems to consist of wrapping the result of what are essentially sync functions in a Promise.resolve. Is there a way to skip this? There are parts of my application where I cannot run async code.

For now, although the API is internal, you can keep using const { internalInsertMany } = require('blinkdb/dist/core/insertMany') to import the synchronous methods.
In the future (after v1.0), I will extract the entire synchronous database into a @blinkdb/core module, which will make it easier if you just want to use the underlying synchronous DB implementation without any hooks.

internalInsertMany still returns a promise though. I hadn't looked closely enough.
WRT hooks, even if I were to de-promisify the internal methods, they still wouldn't trigger hooks then, right? That would be a problem for me, alas. There are sections of my code where I have no choice but to use sync methods.
Is there a rough timeline how far off this future is?

Is there a rough timeline how far off this future is?

I'll get to it as soon as I finish the vue package, which is the current item on my todo list. I'd expect the extracting to @blinkdb/core to be done probably by end of this year.

Any news on this?

@maradotwebp I have a series of putout codemods that strips blinkdb to sync but I'd much prefer it if it would be part of a formal release.


Fix audio UI in uploader for Chrome

Looks like they changed the default to be super bulky:

Fixed in 160a83b5404b5dddb9efc32340e72ebda4abb507