travis support .net core sdk

travis support .net core (osx, linux) sdk using dotnet key with language csharp

added https://github.com/fsharp/FAKE/pull/1281#issuecomment-245340969 , fake helper are using wrong path for dotnet

ok @forki this fix the build and use the already installed .net core sdk in travis (faster).
Paket should build in developer machine too (in my machine works), because now is using the already installed .net core sdk (.net core sdk is a prerequisite, it's useless to install it each time) and doesnt give you an error like you had locally last time because wrong paths.
i added the workaround for dotnet path here so paket work now
I think is the right thing to do in FAKE too, i'll try to send a pr to @matthid pr

@enricosada

.net core sdk is a prerequisite, it's useless to install it each time

The same argument goes for any dependency. I often use fake/paket to install dependencies just to make builds more reproducable/stable across machines. In general I prefer local over global installs (almost always)...

i it still installing the sdk if we don't have it? I liked that idea

this repo can install .net core sdk with the fake script, np for me, but the fake script is bugged atm so this workaround the issue and make build green. Also for developers who have it already installed.
about global/local install ok, but that's a ci server, if they give us a supported way to do it i think we should use that (it's their bandwidth we are using) if possible. And the build matrix support dotnet key too.

Thanks buddy

@forki i added some comment about .net core sdk and FAKE in https://github.com/fsharp/FAKE/pull/1281#issuecomment-245530087
i like the idea of install deps too


Accessing the different structs of pointcloud.mat

Thank you very much for providing the dataset.
I am currently trying to access the data in the pointcloud.mat . Unfortunately I don't have access to matlab so I tried to open it with some HDF5 libraries with python but somehow I just got strange references, but no clear data structure (as can be seen in the screenshot in issue #14). Therefore my first  question is if you used besides Matlab another program/Library to access the pointlcoud.mat file ?
As I am especially highly interested in the BBox data for the 3D point cloud I would also be interested if it is accessible also at another place (in the only 3D dataset I didn't find it)  ?
Last question : The BBox parameter are estimated by looking at the pointcloud of the object and searching for the min/max values of this pointcloud for the different coordinates ?

Access the Matlab file in other sources: No, we haven't tried it in other programs/libraries.
Bbox data: This information is not contained elsewhere, however, as you pointed out, you can easily compute them by finding the min-max values per axis for each object. If you prefer to work on point clouds, you can find the corresponding data at the Stanford Large-Scale 3D Indoor Spaces Dataset (S3DIS) (description, download link).


"Search and replace" adds overscroll margin only sufficient for "search"

Issue Type: Bug
Steps to reproduce:

Open a file.
Open search and replace with Ctrl+H.
Widen the panel so you can see how much text it overlays.
Try to scroll up far enough so that the S&R panel does not overlay the first line of text. Expected: the text becomes fully visible. Observed: the top of the text remains hidden under the panel, because you cannot scroll up far enough.
Collapse the S&R panel by clicking on the chevron on the left side of the panel, so that it becomes a search panel only. The text is now completely visible.
Expand the panel again.
The panel overlays the text again, but now you can scroll up further so that the text becomes completely visible, even with the additional "replace" row.

Tested with all extensions disabled.
VS Code version: Code 1.31.1 (1b8e8302e405050205e69b59abb3559592bb9e60, 2019-02-12T02:20:54.427Z)
OS version: Windows_NT x64 10.0.17134

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz (8 x 2808)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: enabledsurface_synchronization: enabled_onvideo_decode: enabledwebgl: enabledwebgl2: enabled

Memory (System)
15.86GB (10.77GB free)

Process Argv
<file path here; removed by LWChris for privacy reasons>

Screen Reader
no

VM
0%

Extensions: none

@rebornix Can you link to the issue this is a duplicate of?


Set a default value for atol where it appears?

Interestingly, assert_allclose_up_to_global_phase has a comment explicitly recommending against specifying a default atol:
def assert_allclose_up_to_global_phase(
        actual: np.ndarray,
        desired: np.ndarray,
        *,  # Forces keyword args.
        rtol: float = 1e-7,
        atol: float,  # Require atol to be specified
        equal_nan: bool = True,
        err_msg: Optional[str] = '',
        verbose: bool = True) -> None:

This was suggested by @Strilanc in https://github.com/quantumlib/Cirq/pull/729. @dabacon

Part of the reason to make sure to specify atol for assert_all_close_up_to_global_phase is likely that we are modeled after numpy's downstream is_close.  Numpy's method is not symmetric.  The guidance in documentation https://docs.scipy.org/doc/numpy-1.15.0/reference/generated/numpy.isclose.html is that you should select this carefully (also known as until your tests pass).  That said, even numpy has defauls for rtol and atol.
My suggestion is that if our tools delegate rtol and atol they should use numpy's defaults.

I think for testing methods it is best for each test to specify its tolerance. It is convenient to have default tolerances (and we do have this in some places) but really it is something that should be thought about for each comparison IMO. I'll close this pending someone else feeling strongly enough to re-open it.


Is there a way to prevent  to delete both the opening and closing part of the pair?

After a fun day of updating and tweaking my setup I seem to have one annoyance left, and that is that backspace deletes the pair even if its empty (which I would like to prevent).
So I like the general behavior (al lot), but wonder if I can get it to do this:
""| > bs > "| so leaving the opening part, instead of what it does now (removing the whole pair): ""| > bs > |
This seems related to the fact there is noting in between the quotes as otherwise if doesn't remove the first quote:
"something"| > bs > "something|

I haven't yet added a general option to do this.
Whatever, here's a config for that (you can extend it with more ifs):
{
  extensions={cond={cond={function (_,o)
    if o.key~=vim.api.nvim_replace_termcodes('<bs>',true,true,true) then return true end
    if o.line:sub(o.col-2,o.col-1)=='""' then return false end
    return true
  end}}}
}

Cool, thanks for that! That should get me going 👍🏻


search: fix not emit on-change and input events when cancel or clear

Please makes sure the items are checked before submitting your PR, thank you!

[x] Rebase before creating a PR to keep commit history clear.
[x] Only One commit
[x] No eslint errors

Codecov Report

Merging #2315 into v2 will decrease coverage by 0.04%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##               v2    #2315      +/-   ##
==========================================
- Coverage   20.42%   20.37%   -0.05%
==========================================
  Files         213      213
  Lines        5190     5192       +2
  Branches      591      591
==========================================
- Hits         1060     1058       -2
- Misses       4021     4025       +4
  Partials      109      109

Impacted Files
Coverage Δ

src/components/search/index.vue
5.88% <0%> (-0.25%)
:arrow_down:

src/components/selector/index.vue
13.95% <0%> (-4.66%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bd46fb8...ba085b9. Read the comment docs.

目前会出现以下情况：


Solve copying on block device problem

Before calling bmap::copy the output target was truncated. This is good
if it is a file but when it encounters a block device path it returns:
EINVAL: Invalid argument
Now we are checking first if the output target is a regular file, to
avoid that case.
Closes: #11
Signed-off-by: Rafael Garcia Ruiz<EMAIL_ADDRESS>

bors r+

bors try

bors r+


chore: fix, improve, speedup recovery

I've got a report of slow recovery, so I investigated using fedimint-cli to recover in one of test (but otherwise real-like) Fedrations I have available.
I found a serious problem, improved some minor stuff and decided to increase parallism level for significant speedup.
Implementing fetching every session outcome from a single peer would be a significant improvement that could further reduce recovery time.

@maan2003 can you take a second quick look please?

@dpc clippy is unhappy :cry:

@dpc can you rebase on master please? I'm pretty sure GitHub is confused about a commit of this PR already being on master. https://github.com/fedimint/fedimint/commit/8c4b6dcb6eb7d1e2d80fc39c0796f0e6837ed7e3

Backport failed for releases/v0.3, because it was unable to cherry-pick the commit(s).
Please cherry-pick the changes locally and resolve any conflicts.
git fetch origin releases/v0.3
git worktree add -d .worktree/backport-4970-to-releases/v0.3 origin/releases/v0.3
cd .worktree/backport-4970-to-releases/v0.3
git switch --create backport-4970-to-releases/v0.3
git cherry-pick -x 871672d8e9ec8ce4fd49d171e26c061a393129b7 b7d5d2c2c26534597e9609e120e935315a3fa709 f1ad8dc271b3f1ba8cab677ead3145c9766e6b0d 272ee336b176a1f8ea21f1017f3be7df61244efa 2fdac29007864362b18e905e6fd769d8b2ba4acd


Mod Time

This PR extends the objects with a mod_time field. That field used to be a "virtual field", we were just returning the object's created_at time stamp as the mod_time. This does not play well with rclone (among other things probably) so I added a column, used created_at as the default value for objects that already exist, and I start using the X-Amz-Meta-Mtime metadata that's passed by s3 clients.
This fixes the problem outlined in https://github.com/SiaFoundation/renterd/issues/833 but not entirely. We have to use rclone's --modify-window 1s parameter because otherwise it's complaining about ms differences in mod times.
I've confirmed that mod times reach the database with nanosecond precision, however the s3 head object response returns the Last-Modified headers in the following format Thu, 06 Jul 2023 12:10:06 GMT.. so we're losing precision there. Still kind of confused as to how I'm expected to avoid losing the precision there.
2023/12/18 22:04:49 DEBUG : dl_baseline.txt: Size and modification time the same (differ by -545.765768ms, within tolerance 1s)
2023/12/18 22:04:49 DEBUG : dl_baseline.txt: Unchanged skipping

rclone lsl renterd:default
10156 2023-06-05 23:43:34.000000000 benchmark/dl_baseline.txt

select object_id, mod_time from objects where object_id LIKE "%baseline%";
object_id	mod_time
/benchmark/dl_baseline.txt	2023-06-05 23:43:34.546

closing in favour of https://github.com/SiaFoundation/renterd/pull/843


Consider using config state instead of genesis transaction

I mean, we did not need any instructions for the genesis domain and account registered, which means we already have an assumption on the initial state across peers. Also, the genesis transaction goes through no validations. If so, why not have wonderland, alice, executor, chain ID, etc. as a configurable initial state?

Originally posted by @s8sato in https://github.com/hyperledger/iroha/pull/4673#discussion_r1622376516

can we get a more detailed description what is this about?

After #4225 and #4555, the only advantage I can think of for working on this ("genesis state", essentially same as #4409) is to remove a branch of whether it is genesis round or not. I'm not sure if it would be a benefit


The task content can't show on webui-aria2

Hi
The task content can't show on Aria2 Web Frontend
I found some errors on console
this (http://i.imgur.com/iIZ86ZK.png)
and this
jquery-2.1.3.js:8693 GET https://token:secret@<IP_ADDRESS>:6800/jsonrpc:6800/jsonrpc?jsoncallback=jQu…xPcHRpb24iLCJwYXJhbXMiOlsidG9rZW46cGlOYXBQbGUiXX1dXQ%3D%3D&_=1460633989927
net::ERR_CONNECTION_CLOSED
send @ jquery-2.1.3.js:8693
jQuery.extend.ajax @ jquery-2.1.3.js:8161
ariaRequest @ jsoncall.js:16
invoke @ jsoncall.js:37
invoke @ syscall.js:42
update @ rpc.js:89 js
oncall.js:46 jsonrpc disconnect!!!

my JSON-RPC Path is
https://token:secret@127.0.01:6800/jsonrpc

What should I do to fix this problem?
Thanks

Problem on screenshot: you are querying insecure resource (over http) from secure page (over https). This is not allowed in browsers.
Secure pages can only request secure content.
Aria2 allows ssl usage (see https://aria2.github.io/manual/en/html/aria2c.html#cmdoption--rpc-certificate), but it needs valid certificate. Self-signed certificates won't work either.
If you supply Aria2 with valid certificate, don't forget to enable https://aria2.github.io/manual/en/html/aria2c.html?highlight=same origin#cmdoption--rpc-allow-origin-all.
Your second error seems to be misconfiguration: server just drops every connection. Most likely, you tried  to use secure connection without enabling options mentioned above.
In order to make it work you need to:

serve Aria2 using secure connection or serve your page from insecure source
serve Aria2 and page from same source or set --rpc-allow-origin-all=true option

Thanks I had solved the problem

Well, you can close this issue then.

close

@KwToPA, I mean you should close this issue. It can only be closed by repo owner, who is not showing here too often or the one who opened this issue. You should have button "Close this issue" somewhere on this page.

Ooops


Add ability to archive files

Review Checklist

Tests were added to cover all code changes
Documentation was added / updated
Code and tests follow standards in CONTRIBUTING.md

Looks like this branch is off another branch - reset?

Code appears to be reset.
PR does not get an LGTM from me, but does get a shrug. Merge as desired.

@nagem
Is this change purely additive? Does it align at all with priorities for the next 4 months? Looking for input on abandoning vs. pushing this through. Thanks!

Closing this PR as it is covered in new PR separate from classification changes.


Is this using the latest version of gatsby?

I'm on Windows and really like the idea of using docker to get around all the different OS idiosyncrasies. Is this up to date?

This is just for building & hosting Gatsby websites — if you want to develop Gatsby in Docker, you'd need another image. Probably just something that's setup for Node.js development. Not really sure what that'd be but if you find a great setup, I'm sure others would love to hear back about it!

I found this:
https://hub.docker.com/r/asifrc/gatsbyjs-dev/~/dockerfile/
Look promising?
On Fri, Dec 8, 2017 at 11:45 AM, Kyle Mathews<EMAIL_ADDRESS>wrote:

This is just for building & hosting Gatsby websites — if you want to
develop Gatsby in Docker, you'd need another image. Probably just something
that's setup for Node.js development. Not really sure what that'd be but if
you find a great setup, I'm sure others would love to hear back about it!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/gatsbyjs/gatsby-docker/issues/10#issuecomment-350311224,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADQBP7iyiN-eEc5hLYCR581qMvfkRMn6ks5s-We7gaJpZM4Q7OEW
.

Looks old as they're on node 6 and expose port 3000 which we stopped working but should still work!

Does this look better:
https://hub.docker.com/r/optimized/docker-gatsbyjs/
Sorry, I'm new


Use chaos version 0.8.1.

Can you make sure, the response times are in the log?
Tried 2 requests. The first one has an additional number (response time?). Why not both?
Related: is it possible to remove the time stamp - it is included twice?
marathon [2015-10-14 09:59:45,656] INFO 0:0:0:0:0:0:0:1 - - [14/Okt/2015:07:59:45 +0000] "GET //localhost:8080/v2/apps HTTP/1.1"<PHONE_NUMBER> "-" "HTTPie/0.9.2" 13 (mesosphere.chaos.http.ChaosRequestLog$$EnhancerByGuice$$68f42fa6:qtp1598898814-33)
marathon [2015-10-14 10:02:22,595] INFO 0:0:0:0:0:0:0:1 - - [14/Okt/2015:08:02:22 +0000] "GET //localhost:8080/ui/ HTTP/1.1" 200 395 "-" "HTTPie/0.9.2"  (mesosphere.chaos.http.ChaosRequestLog$$EnhancerByGuice$$68f42fa6:qtp1598898814-33)

The extra number is the request time and both lines should have it, it is added by a Jetty lifecycle plugin here:
https://github.com/confluentinc/rest-utils/blob/master/core/src/main/java/io/confluent/rest/logging/AbstractNCSARequestLog.java#L221
The date is also written by that plugin, I'll try setting the date format to "".

Setting the date format to "" removes the date from the message, but keeps the surrounding []:
marathon [2015-10-14 12:26:15,104] INFO 0:0:0:0:0:0:0:1 - - [] "GET //localhost:8080/v2/apps HTTP/1.1" 200 11 "http://localhost:8080/ui/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36"  (mesosphere.chaos.http.ChaosRequestLog$$EnhancerByGuice$$f6e78037:17)
To completely remove it, we'll have to override AbstractNCSARequestLog#log.


chest connections seem to be broken

sometimes items transfer to the construction chest, sometimes to somewhere unknown, but not to the connected chest

Hi, are you on the latest version?
This was already fixed here: https://github.com/notnotmelon/factorissimo-2-notnotmelon/issues/55

Possibly related: https://github.com/notnotmelon/factorissimo-2-notnotmelon/issues/65


Memory Warning While Applying any filter on video got by LivePhoto(Apple Live Photo)

Hello
I have applied GPUImageFilter in my App which is useful to filter live photos into GIF. It works amazing for the portrait and normal live Pics. I use both GPUImageMovieWriter and MovieView to Play and Save Video. It Works very Nice.
But, When I Use same for Live Photo (Original taken by iPhone). It gives me memory warning on Movie to play it and after 4 memory warnings, It crashes the App. Please help me.
Thanks.

resolution of apple Live Photo is   {2272, 1704} any issue because of this????

Solved :: I've tried by making resolution low and it worked..


feat: Add ArangoDB module

What does this PR do?

Adds an ArangoDB container to the list of supported Testcontainers.
Why is it important?

Provides an ArangoDB test container.
How to test this PR

Run Testcontainers.ArangoDb.Tests.

Thanks @HofmeisterAn!

Here you can see the preview in the Module Catalog.


Create changelog process to generate changelog automatically

I guess to generate our update logs for the public, the best would be to handle it right away from PRs as it could be made easily and automatized like https://blog.atomist.com/keep-a-changelog/
The goal will be to use releases and generate changelog.md like those https://github.com/olivierlacan/keep-a-changelog/blob/main/CHANGELOG.md
Abhisar will take look on that:)

Hi,
So I found two good options for us to use regarding changelogs.

auto-changelog : NPM Package or Git Repo
This needs to be installed as a dependency and would automatically add a changelog.MD in the root with changes. The Tutorial is extensive and the repo is regularly updated.

Automatic Changelog generator. GitHub Marketplace. This is a free product in the GitHub MarketPlace. It has more options and flexibility but is directly installed on the GitHub repository and runs in the background.

I feel both of them have pros and cons and would be a good idea if it can be tested on a branch or locally first. I'll continue to look for more options but these two seem pretty positve.

This might help.

Just in time! Briefly skimming, that's looks exactly what we should have
there!
On Tue, Oct 5, 2021 at 3:51 PM roiLeo @.***> wrote:

This
https://github.blog/2021-10-04-beta-github-releases-improving-release-experience/#introducing-auto-generated-release-notes
might help.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kodadot/nft-gallery/issues/734#issuecomment-934434817,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABM5POKRKDFDO45X6PO5S3LUFL7HFANCNFSM5EEIYGKQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

First can go out I think
https://github.com/kodadot/nft-gallery/releases/tag/untagged-5bd022b71f4c3efa83c3


trace of array chosen

we have chosen trace of array for our work

If this is not possible we are doing return of diagnol.

@poojashresthacode we group 3 has already chosen this. Please be informed.

@reshnashrestha Which one did you choose? Trace of an array?

@reshnashrestha Yes, we choose returning diagonal.


perf(ASGI): WiP: tune ASGI request-response cycle performance

Work in progress:

[x] Speed up ASGI scope validation (or make concessions and be less strict)
[x] Speed up Response headers (I won't have the time to complete this right now)
[x] Avoid unnecessary function calls (where reasonable)
[ ] Avoid unnecessary awaits (where reasonable) :arrow_left: work in progress
[x] Speed up Request.__init__()
[x] Restore 100% coverage

Some test cases and results regarding request header decoding (see my comment on the gist): https://gist.github.com/kgriffs/fa31baf256d81ef6e4bb1b401b4e3dae

I updated my gist with some additional findings: https://gist.github.com/kgriffs/fa31baf256d81ef6e4bb1b401b4e3dae

I updated my gist with some additional findings: https://gist.github.com/kgriffs/fa31baf256d81ef6e4bb1b401b4e3dae

I'm looking to attempt inlining Response.render_body() in order to shave off 1 await, but this should be otherwise ready to review.
This PR improves about performance about 10-15% compared to master.
And makes us faster than Starlette in a "Hello, world" type of benchmark in an isolated pseudo-async loop.
However, on real Uvicorn, Starlette is still somehow magically faster... :thinking:


Feature request: Tracer should log warning instead of throwing when segment is not found

Expected Behaviour
Today, for an unknown reason in one of our Lambdas in Production, the Tracer object was unable to retrieve the current Segment from X-Ray.
Because the Segment was attempted to be retrieved in the middy middleware at the beginning of every request (here) it caused every Lambda request to fail until we forced a cold-start of the Lambda, which resolved our problem.
It caused the request to fail because the Tracer throws an error if the Segment returned is undefined.
Unfortunately our Lambda was kept warm for over an hour before we tracked it down and forced a cold-start. In the meantime every request failed (see execution logs below).
My expected behaviour would be that if a Segment could not be retrieved, that it doesn't cause the whole Lambda invocation to fail, which it currently does when using the middy middleware.
Tracing should be done on a best-effort basis, if there is any problem tracing a request it should not cause the main request itself to fail. This particular scenario of getting the Segment is one specific case that could be improved to avoid failing the request, but it's quite possible there may be other code-paths that are vulnerable to causing the main request to fail, particularly if instrumented by the captureLambdaHandler middy middleware.
Current Behaviour
As mentioned above, the Tracer currently throws an error if the Segment returned is undefined, this causes the middy middleware to fail every request, since getSegment() is called in the captureLambdaHandlerBefore function (here).
Code snippet
You could wire in a dummy Tracing provider to return undefined from its getSegment() method, called here.
Steps to Reproduce
We don't know yet what caused aws-xray-sdk-core's getSegment() (here) to return undefined, but if you can simulate that, and use the captureLambdaHandler middy middleware, you will find that it causes the wrapped request to fail.
For us it caused the request to fail until the function was cold-started since getSegment() never started returning a Segment object.
Possible Solution
My suggestion would be to consider updating the Tracer.getSegment() method to log a warning and return a dummy SubSegment if a real segment couldn't be retrieved, similar to how it already does if tracing is disabled.
Something like as follows:
  public getSegment(): Segment | Subsegment {
    if (!this.isTracingEnabled()) {
      return new Subsegment('## Dummy segment');
    }

    const segment = this.provider.getSegment();

    if (segment == null) { // changed from === undefined to be slightly more robust in case null is returned somehow
      // throw new Error('Failed to get the current sub/segment from the context.');
      console.warn('Failed to get the current sub/segment from the context, so failing over to manually create one to allow the request to proceed.');
      return new Subsegment('## Fallback segment (as unable to retrieve existing Segment)');
    }

    return segment;
  }

AWS Lambda Powertools for TypeScript version
1.6.0
AWS Lambda function runtime
18.x
Packaging format used
Lambda Layers
Execution logs
2023-03-07T17:08:23.043Z	xxxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxx	ERROR	Error: Failed to get the current sub/segment from the context.
    at Object.contextMissingLogError [as contextMissing] (/var/task/index.js:15505:23)
    at getSegment (/var/task/index.js:15569:49)
    at ProviderService.getSegment (/var/task/index.js:20115:51)
    at Tracer2.getSegment (/var/task/index.js:20539:39)
    at open (/var/task/index.js:20841:32)
    at captureLambdaHandlerBefore (/var/task/index.js:20852:11)
    at runMiddlewares (/var/task/index.js:24918:23)
    at async runRequest (/var/task/index.js:24876:5)

2023-03-07T17:08:23.043Z	xxxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxx	ERROR	Error: Failed to get the current sub/segment from the context.
    at Object.contextMissingLogError [as contextMissing] (/var/task/index.js:15505:23)
    at getSegment (/var/task/index.js:15569:49)
    at ProviderService.getSegment (/var/task/index.js:20115:51)
    at Tracer2.getSegment (/var/task/index.js:20539:39)
    at Tracer2.addErrorAsMetadata (/var/task/index.js:20209:33)
    at captureLambdaHandlerError (/var/task/index.js:20867:18)
    at runMiddlewares (/var/task/index.js:24918:23)
    at runRequest (/var/task/index.js:24902:13)

2023-03-07T17:08:23.044Z	xxxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxx	ERROR	Invoke Error 	{
    "errorType": "Error",
    "errorMessage": "Failed to get the current sub/segment from the context.",
    "originalError": {
        "errorType": "Error",
        "errorMessage": "Failed to get the current sub/segment from the context.",
        "stack": [
            "Error: Failed to get the current sub/segment from the context.",
            "    at Tracer2.getSegment (/var/task/index.js:20541:17)",
            "    at open (/var/task/index.js:20841:32)",
            "    at captureLambdaHandlerBefore (/var/task/index.js:20852:11)",
            "    at runMiddlewares (/var/task/index.js:24918:23)",
            "    at async runRequest (/var/task/index.js:24876:5)"
        ]
    },
    "stack": [
        "Error: Failed to get the current sub/segment from the context.",
        "    at Tracer2.getSegment (/var/task/index.js:20541:17)",
        "    at Tracer2.addErrorAsMetadata (/var/task/index.js:20209:33)",
        "    at captureLambdaHandlerError (/var/task/index.js:20867:18)",
        "    at runMiddlewares (/var/task/index.js:24918:23)",
        "    at runRequest (/var/task/index.js:24902:13)"
    ]
}

Hi @danrivett thank you for reporting this, I'll review the report tomorrow morning (EMEA time zone) and write here my findings.
If needed after finding and applying a fix, I'm open to do an emergency release to avoid further outages.

Thanks for such a quick response @dreamorosi especially given your timezone.
For now we're looking at deploying the following workaround to wrap Tracer.getSegment() based off my suggested fix in this ticket, so that should avoid the need for an emergency fix and allow more time to evaluate the best solution.
export class CustomTracer extends Tracer {
  public constructor(options?: TracerOptions) {
    super(options);

    this.getSegment = this.getSegment.bind(this);
    this.createFallbackSubSegment = this.createFallbackSubSegment.bind(this);
  }

  getSegment(): Segment | Subsegment {
    try {
      return super.getSegment();
    } catch (error) {
      console.error(
        'Failed to get the current sub/segment from the context, so failing over to manually create one to allow the request to proceed.',
        error
      );
      return this.createFallbackSubSegment();
    }
  }

  protected createFallbackSubSegment(): Subsegment {
    return new Subsegment(
      '## Fallback segment (as unable to retrieve existing Segment)'
    );
  }
}

Note: This external fix is slightly different from the one suggested above because I'm wrapping the whole Tracer.getSegment() method call with is currently throwing an error, rather than altering how that method responds to undefined being returned from this.provider.getSegment().

So, I've started looking into this and on the Powertools' side, I was able to reproduce the behavior with this unit test case:
test('when no subsegment is returned, everything blows up', async () => {

  // Prepare
  const tracer: Tracer = new Tracer();
  jest.spyOn(tracer.provider, 'getSegment')
    .mockImplementationOnce(() => undefined);
  const lambdaHandler: Handler = async (_event: unknown, _context: Context) => ({
    foo: 'bar'
  });
  const handler = middy(lambdaHandler).use(captureLambdaHandler(tracer));

  // Act & Assess
  await expect(handler({}, context)).rejects.toThrowError(
    Error('Failed to get the current sub/segment from the context.')
  );

});

Now, by looking at the logs in the OP, and looking at the call stack in them, it seems that the first getSegment call that failed was the one in the before lifecycle stage of the middleware (here), as opposed to the one linked in the OP which is in the after phase (see below, line annotated with /// HERE ///):
2023-03-07T17:08:23.043Z	xxxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxx	ERROR	Error: Failed to get the current sub/segment from the context.
    at Object.contextMissingLogError [as contextMissing] (/var/task/index.js:15505:23)
    at getSegment (/var/task/index.js:15569:49)
    at ProviderService.getSegment (/var/task/index.js:20115:51)
    at Tracer2.getSegment (/var/task/index.js:20539:39)
    at open (/var/task/index.js:20841:32)
    at captureLambdaHandlerBefore (/var/task/index.js:20852:11) <--- /// HERE ///
    at runMiddlewares (/var/task/index.js:24918:23)
    at async runRequest (/var/task/index.js:24876:5)

This points to the fact that for some reason the X-Ray SDK returned undefined, which is strange.
I need to investigate a bit further to try to understand why that could have happened, but as far as I remember this shouldn't happen unless AWSXRay.getSegment (here) was called outside of the context of a function invocation. However the call stacks in the logs you shared don't seem to indicate that.
I agree that the behavior of throwing an error is not explicitly documented, and that in most cases the current behavior might not be the best/desired one. However, strictly speaking I'm not sure yet if this should be marked as bug, given that Tracer behaved as it was supposed to (aka throw an error when no segment is returned).
With that said, I'm open to discuss and explore the possibility to change this into a warning like you suggested, or to at least give users a way to decide the behavior similar to what the X-Ray SDK does with the setContextMissingStrategy method.
In the meanwhile, would you be open to share the final log of a few of these faulty executions? I'm looking to see, if possible, the report log and see if the tracing-related info were present. If you prefer to do so in a less public forum, you can also email them at<EMAIL_ADDRESS>

Would like to amend a section of my previous comment:

I need to investigate a bit further to try to understand why that could have happened, but as far as I remember this shouldn't happen unless AWSXRay.getSegment (here) was called outside of the context of a function invocation. However the call stacks in the logs you shared don't seem to indicate that.

After looking again at the logs you provided, and specifically at the call stack, we can see in the first line of each log error this line:
at Object.contextMissingLogError [as contextMissing] (/var/task/index.js:15505:23)

Based on this entry of the call stack, it seems that the root cause of the issue is the fact that both the X-Ray SDK and Tracer were not able to find any trace data. This usually happens when trying to retrieve a segment or perform actions on it outside of the context of an invocation.
To continue with the investigation, could you please also provide two more pieces of info:

Which version of the X-Ray SDK are your Lambda functions running? I'm asking this because in 3.4.1 the SDK changed its behavior around missing context from throwing a runtime error to logging (PR here). Based on the call stack it seems you might be using that version (for context, Powertools still pins the previous one)
Any chance you could also share the high level structure of your function, the exported handler (not its content), and how you're using the middleware (plural)? Based on what I discussed above it seems that somehow the middleware is running outside of the Lambda context, although it's very strange and shouldn't happen

More details on how the AWS X-Ray SDK (from now on referred as SDK) resolves the trace context/data, note that all this happens upstream of Powertools.

The first time that the SDK is imported, an IFEE defined here is called.
This function configures the SDK to works in Lambda by setting some configs.
After that, a namespace and context are created, and the first facade segment is set
Up to this point, the facade segment is not valid and it's a dummy one as we are still outside of the scope of the actual function handler

Now, the codepath that leads to the stack in your logs, as far as I know, can be triggered only by first calling one of these three methods of the SDK:

getSegment, which corresponds to this implementation
setSegment, which corresponds to this implementation
resolveSegment, implemented here, which you probably won't be using in userland and that is usually called by one or the other two under the hood

All these methods are related to segment and context and the reason why is that is because the SDK stores the current segment in this context object (from this package which acts as custom implementation/polyfill of Async Hook present in more modern Node.js versions).
In a "regular" execution, the codepath executed should be this, which essentially tells the SDK to create a new facade segment, this time using the info coming from the Trace data present in the environment.
If we look at the logic of these three methods,  the error related to the contextMissing can be triggered only if said methods were called outside of the context of a lambda execution, i.e.
import { getSegment } from 'aws-xray-sdk-core`;

const segment = getSegment(); // <- This will trigger a context missing

export const handler = () => {};

I know the example above is extremely trivial and simplistic, but is there any chance that this could be happening somewhere in your code, either outside of the handler or in middleware that run before  there any chance that

Thank you so much @dreamorosi for taking such a timely and detailed look into this bug report. It really is greatly appreciated.
It is still early on the west coast here, and we still have some actions remaining from the outage yesterday that I need to attend to first, but I will respond later today with more information that you requested. I will post what I can here, and the rest I will email.
However three brief updates:

We aren't calling X-Ray directly, in fact I had to add the aws-xray-sdk-core package to our package.json file in order to code the workaround solution above and manually new up a Subsegment object.
We do have other middleware installed, namely other Powertools middleware such as injectLambdaContext provided by the Logger, but also custom middleware.

As examples, some of these middleware translate errors thrown of a certain type (ClientError in our case) into being a return error object rather than throwing the error (this is because it's invoked by AppSync and we want to be able to return the equivalent of 400s without marking our Lambdas as in error when they work as designed)
Other middleware also has global input policing to ensure that certain fields match our rules (because AppSync doesn't allow for custom scalar types (such as these common ones) 🙏
Therefore it's possible and we believe did happen in our cases detected so far that another middleware layer threw an error. However there are many other invocations that this has happened that hasn't caused this reported issue, so if that is affecting this, it doesn't affect it very often for us.
And I want to be clear that although an error was thrown by another middleware for one request, the Tracer middleware continued to fail for all requests until we manually redeployed it an hour later and cold-started it.

The key thing here though is the error becomes permanent until the function is destroyed and a new one is cold started. All our subsequent functions that passed middleware checks failed with the reported error above.

My final point though, is that regardless of the above, I think there is a design decision that needs to be carefully thought through and made: should an error in any instrumentation middleware - such as this X-Ray one, but not limited to that - be severe enough to warrant not executing the wrapped underlying function successfully?
One can argue both sides to this, but as I mentioned above I view instrumentation as best-effort and auxillary, and shouldn't itself prevent the underlying function from executing if it encounters an error.
This could of course be configurable, and although I wouldn't recommend it, the default could be to block the execution of the underlying function if it encounters an error, as there are valid reasons for this. As I mentioned we have middleware with polices the input, so of course we want those errors to block execution of the underlying function. But I don't view the failure of tracing instrumentation as cause for blocking the execution of the underlying function. I would much rather log a warning and alert off of that for us to investigate.
So regardless of the root cause of why this.provider.getSegment() returned undefined in Tracer.getSegment(), I think a decision needs to be made and documented about whether the Powertools instrumentation middleware should try to run on a best-effort basis, and in that case it should not choose to throw errors that will prevent the underlying function from executing, unless absolutely necessary.
To put this in context, there was a real customer impact for over an hour yesterday because of the errors being thrown, I'd argue not tracing those requests and allowing them to proceed in this error scenario is a much better alternative, which is why I am putting so much effort in explaining my reasoning.
We can always and should work to fix the root cause of issues (that's part of my investigation today), but there will always be bugs and so I feel we have to decide if we want to design middleware that gives the underlying request the greatest chance of success and so tolerate certain error scenarios what shouldn't but can happen.
One final addendum: The workaround above seems to be working well for us, overnight we had 8 function invocations out of 12,000 which encountered, but they failed over and didn't cause subsequent executions to fail until the next cold start.

Interesting that those invocations were clustered too, which is something I'll look into.
Thanks again @dreamorosi your huge efforts on this library and helping customers is not unnoticed and very appreciated.

Thank you for the additional details, I just wanted to clarify that my investigation for a root cause is not to defer responsibility to another package or to your code but only to try to identify the actual issue that caused the outage, and try to understand if this is something that is inherent to Tracer, and if so, that should be fixed so that it doesn't affect other customers.
The above is separate and independent from the fact that as you say tracing throwing an error should not break the whole middleware stack. I agree with that and after looking at the X-Ray SDK, which recently changed their default behavior to just log when this happens, I think we should do the same.
I'm happy to move forward with this fix, however if you are available I'd still like to understand what caused the issue. I'm concerned that if we apply the fix and just log, we'll be patching the behavior (aka the error being thrown), but we wouldn't be fixing the actual issue that caused it. However I also understand that you might have other priorities or not be interested in dedicating time to this, so if that's the case I 100% understand and there's no expectation whatsoever from our side on you doing that.

Thanks @dreamorosi I definitely want to provide additional info to help determine the root cause - we ourselves want to also understand that for similar reasons. My gut is there is an edge condition somewhere, possibly in the X-Ray SDK, but could easily be outside that too, it's too early for me to draw many conclusions.
I've been continuing to investigate, and it's still ongoing, but I do have some additional information I've uncovered that I can share here below (I'm about to head into meetings so it will be straight after as I ran out of time).
But first I want to clarify an incorrect observation I made above (that's the danger of reporting timely but prematurely) - those 8 function invocations were not clustered, and in fact were 4 function invocations and each error had two log entries that matched by my query (one from the log message from aws-xray-sdk-core itself, and the other from our failover logged warning).
I thought it was worth updating on that as those 4 cases were isolated and not clustered as I first thought.

The additional info I've found so far centre on the 4 failed over requests overnight, I think it should be helpful to your investigation too.
All 4 of these showed the same pattern:

We received a Lambda request which one custom middleware function threw an error policing input - in all 4 cases it was due to an empty id field being passed in, since AppSync currently can only police that a field is required, but not that it's non-empty (see the custom scalar type discussion above).
A second middleware function intercepted the error thrown as it was of type ClientError (which as I mentioned above is a super class we use to allow us to return client error objects) and this middleware function returned an error object response, swallowing the error.

It's worth pointing out that this request finished successfully (with a client error object returned).
Here's what we logged for that first request. This is logged by the 2nd middleware layer which caught the client error and returned the error object:
{
    "cold_start": true,
    "function_arn": "xxx",
    "function_memory_size": 512,
    "function_name": "xxx",
    "function_request_id": "xxx",
    "level": "INFO",
    "message": "ClientError (InputError) caught ('Input.BusinessIdMissing'); returning error object to requestor.",
    "service": "xxx",
    "timestamp": "2023-03-08T01:20:35.328Z",
    "xray_trace_id": "xxx",
    "error": {
        "returnObject": {
            "message": "No business id received",
            "error": {
                "type": "Input.BusinessIdMissing",
                "code": "BusinessIdMissing",
                "category": "Input"
            },
            "errorInfo": {
                "fieldName": "businessId",
                "fieldValue": ""
            }
        },
        "class": "InputError",
        "stack": [
            "Error: No business id received",
            "at new InputError (/var/task/index.js:23155:5)",
            "at validateBusinessId (/var/task/index.js:23223:11)",
            "at /var/task/index.js:26810:23",
            "at runMiddlewares (/var/task/index.js:26698:23)",
            "at async runRequest (/var/task/index.js:26656:5)"
        ]
    }
}

We next receive a subsequent Lambda request which has valid input and so no error is thrown by the middleware layer in 1. above.
However the Tracer middleware (captureLambdaHandler) cannot identify the segment, throws an error, which is then caught by our wrapper (see CustomTracer above) and it fails over to a manually created SubSegment.
This request then completes successfully.

Subsequent requests complete successfully too with no additional failover logged, but I'm assuming they're all using the failed-over SubSegment manually created in 4. but I can't prove that. That's my assumption, as before we deployed our wrapper, every subsequent request failed because of the error thrown by Tracer.getSegment().
Important Detail
In all 4 cases, the request in 1. above which failed due to a missing id happened on a cold start. I think this important as an error was thrown by one middleware layer before being caught by another (which I believe is permitable even if unusual) but this error thrown seems to have disrupted AWS X-Ray from being able to obtain the segment correctly.
The fact though that the first request on a cold start was an invalid one, seems to be a key reason why we didn't see Tracer.getSegment() failing after other invalid requests that happened on a warm start. My assumption here is that the Segment has already been initialized in memory so an invalid request doesn't prevent X-Ray retrieving the Segment.
But it's also odd that on the invalid request itself, the captureLambdaHandler doesn't seem to have a problem.
The order in which the middleware functions are added also appears to be contributing because we're currently adding the tracer after the custom middleware because tracer is optional for us (though currently is defaulting to enabled):
mHandler = mHandler
    .use(injectLambdaContext(logger, { clearState: true }))
    .use(verifyRequest(logger)) // <- Error thrown here
    .use(returnClientErrors(logger)); <- Error caught here
}

if (tracer) {
  mHandler = mHandler.use(captureLambdaHandler(tracer)); // <- Tracer middleware added here
}

Looking at this now, my assumption is that on that first request captureLambdaHandler() never has its captureLambdaHandlerBefore function called, since a previous before function threw an error.
I'm not sure if captureLambdaHandlerAfter or captureLambdaHandlerError is still called in that case? My assumption is captureLambdaHandlerAfter is, since returnClientErrors swallows the error thrown and returns an error object.
Either way, both captureLambdaHandlerAfter and captureLambdaHandlerError call close(), and possibly there's a problem in calling close() without first calling open() by captureLambdaHandlerBefore being skipped, but I'm really reaching beyond my understanding at this point.
That explanation doesn't make sense to me because close() also calls Tracer.getSegment() and so I'd assume that first invalid cold-start request would then fail when it was called, and it's not, that request succeeds in returning an error object back to the requestor!
Sorry for so much detail, but I'm not sure what is helpful or not.
I am going to investigate and test moving the captureLambdaHandler earlier to see if that avoids failing over, but I also think it would be beneficial to remove throwing an error in Tracer.getSegment() and warning and failing over instead.
I am also curious if there's a weakness in aws-xray-sdk-core or Powertools Tracer as I'm not sure why prior to us wrapping Tracer it was never able to retrieve the Segment in subsequent requests until it was cold-started again.
Given the above, I think it may be possible to recreate this by creating your own middleware that mimic verifyRequest() and returnClientErrors() to see if you can recreate the part where subsequent requests never are able to get the Segment.
Let me know if there's more info you'd like. Thanks @dreamorosi.

Hi Dan, this is great, and I appreciate you taking the time to share all these info.
I think I have enough to continue the investigation. I'd like to focus my attention to the behavior you have described here:

I'm not sure if captureLambdaHandlerAfter or captureLambdaHandlerError is still called in that case? My assumption is captureLambdaHandlerAfter is, since returnClientErrors swallows the error thrown and returns an error object.

Either way, both captureLambdaHandlerAfter and captureLambdaHandlerError call close(), and possibly there's a problem in calling close() without first calling open() by captureLambdaHandlerBefore being skipped, but I'm really reaching beyond my understanding at this point.

I think you are onto something here, however I need to simulate this middleware stack to confirm our understanding.
I'll continue my investigation tomorrow and report back here.

One note, not necessarily related to this issue/outage, but that I still want to share based on the code snippet you shared above:
mHandler = mHandler
    .use(injectLambdaContext(logger, { clearState: true }))
    .use(verifyRequest(logger)) // <- Error thrown here
    .use(returnClientErrors(logger)); // <- Error caught here
}

if (tracer) {
  mHandler = mHandler.use(captureLambdaHandler(tracer)); // <- Tracer middleware added here
}

If possible, I'd recommend refactoring this to something along these lines:
if (tracer) {
  mHandler = mHandler.use(captureLambdaHandler(tracer)); // <- Tracer middleware added here
}

mHandler = mHandler
    .use(injectLambdaContext(logger, { clearState: true }))
    .use(verifyRequest(logger)) // <- Error thrown here
    .use(returnClientErrors(logger)); // <- Error caught here

The reason why I suggest this is due to how Middy handles the middleware stack (described here). Given your original middleware stack above, the execution order would be like:
injectLambdaContext
verifyRequest
returnClientErrors
captureLambdaHandler
handler
captureLambdaHandler
returnClientErrors
verifyRequest
injectLambdaContext

Unless this was an explicit choice, this means that the captureLambdaHandler is tracing only the content of the actual handler and any time spent in the other middleware is excluded from the segments, but still part of the main Invocation segment generated by Lambda (referred to as facade in a previous message).
Regardless of the handler throwing or not, ideally you'd want the captureLambdaHandler to be the first and last middleware so that the whole execution is part of the segment. Additionally, if there's an error, with Tracer it would be added to the segment as metadata.

Thanks so much @dreamorosi for continuing to investigate and your suggestion on moving the captureLambdaHandler wiring.
It wasn't a deliberate choice, it just seemed the most intuitive to write at the time, but I agree that considering the ordering, it makes more sense to have it first.
It may also work around whatever weakness there appears to be somewhere that causes the Segment to not be resolvable in the scenario above. Either way it will be a good data point so I'll report back after the change with anything I find.

Update on this, I managed to recreate the issue in my dev environment after reverting the failover logic as expected:

On a cold start make a request with an invalid (empty) id

Client Error is returned as desired

Make a valid request

Receive error back with ""

Continue to make valid requests, and all fail with the same error.

Now, when I move captureLambdaHandler earlier as suggested, I'm unable to recreate the issue, instead:

On a cold start make a request with an invalid (empty) id

Client Error is returned as desired

Make a valid request

Receive a valid response

Continue to make valid requests, and all continue to succeed.

So that was a great suggestion @dreamorosi in more ways than one! Thank you.
Possible Follow-up Actions
I still think there is a weakness to investigate as time allows, in why the segment can't be resolved in this case, as it is  possible that captureLambdaHandler may not be the first middleware. Though based on your observations, that may be rare enough to acknowledge and take no further action.
In addition I'd still suggest considering whether throwing errors in this middleware, unless absolutely necessary, is something that should be done longer term.
I am hopeful removing the error in Tracer.getSegment() and failing over may be a good starting point (even if it's less likely to occur based on what we've found out) mainly because of the oversized impact that it had, causing every subsequent request to also fail.
Regardless, feel free to close this ticket off once you've completed any intended actions.

Hi, thank you for reporting back.
I have been investigating this further and I have also got in touch internally with the X-Ray service team to better understand in which cases the SDK could return undefined when retrieving the main segment.
The team has confirmed that this should not happen in normal circumstances while running in Lambda. The getSegment-related methods in the SDK are typed to return undefined because this same SDK supports other execution environments like ECS and EC2, and in these circumstances we cannot guarantee that the Trace ID is well formed, hence the undefined.
In your specific case, without reviewing the code and telemetry, I'm unable to understand exactly why that happened.
Now, regarding the middleware behavior, I was able to confirm that given the following code, aka two custom middleware in which the first one in the stack throws:
import middy from '@middy/core';

const customMiddleware = () => {
  const customMiddlewareBefore = async () => {
    console.log('firstMiddlewareBefore');
    throw new Error("Error in customMiddlewareBefore");

  }

  const customMiddlewareAfter = async () => {
    console.log('firstMiddlewareAfter');
  }

  const customMiddlewareOnError = async () => {
    console.log('firstMiddlewareOnError');
  }

  return {
    before: customMiddlewareBefore,
    after: customMiddlewareAfter,
    onError: customMiddlewareOnError
  }
}

const secondMiddleware = () => {
  const customMiddlewareBefore = async () => {
    console.log('secondMiddlewareBefore');
  }

  const customMiddlewareAfter = async () => {
    console.log('secondMiddlewareAfter');
  }

  const customMiddlewareOnError = async () => {
    console.log('secondMiddlewareOnError');
  }

  return {
    before: customMiddlewareBefore,
    after: customMiddlewareAfter,
    onError: customMiddlewareOnError
  }
}

export const handler = middy(async () => {
  return {
    statusCode: 200,
    body: JSON.stringify({
      message: 'hello world',
    }),
  };
})
  .use(customMiddleware())
  .use(secondMiddleware());

results in this call order:
START RequestId: 5a18ccbf-7015-4133-adb6-981d5f41a307 Version: $LATEST
2023-03-09T18:15:00.505Z	5a18ccbf-7015-4133-adb6-981d5f41a307	INFO	firstMiddlewareBefore
2023-03-09T18:15:00.511Z	5a18ccbf-7015-4133-adb6-981d5f41a307	INFO	secondMiddlewareOnError
2023-03-09T18:15:00.511Z	5a18ccbf-7015-4133-adb6-981d5f41a307	INFO	firstMiddlewareOnError
2023-03-09T18:15:00.512Z	5a18ccbf-7015-4133-adb6-981d5f41a307	ERROR	Invoke Error 	{"errorType":"Error","errorMessage":"Error in customMiddlewareBefore","stack":["Error: Error in customMiddlewareBefore","    at customMiddlewareBefore (/var/task/index.js:7012:11)","    at runMiddlewares (/var/task/index.js:6925:23)","    at runRequest (/var/task/index.js:6882:11)","    at Runtime.middy2 [as handler] (/var/task/index.js:6833:12)","    at Runtime.handleOnceNonStreaming (file:///var/runtime/index.mjs:1085:29)"]}
END RequestId: 5a18ccbf-7015-4133-adb6-981d5f41a307
REPORT RequestId: 5a18ccbf-7015-4133-adb6-981d5f41a307	Duration: 48.62 ms	Billed Duration: 49 ms	Memory Size: 128 MB	Max Memory Used: 71 MB	Init Duration: 248.47 ms
XRAY TraceId: 1-640a2224-466141706af3a2044f3553d1	SegmentId: 16354c752fc51107	Sampled: true

Which I think confirms that in case one of the middleware throws, all the subsequent ones will run the OnError hook.
Before closing this issue I will open a PR to align the Tracer to the current behavior of the SDK and default to log a warning instead of throwing.
Thank you for the help while troubleshooting and investigating this, I appreciate the time you spent to provide info and contribute to improve the library!

Hi Dan, last update on this topic: I have updated the categorization and title of the issue to better align with my understanding of your latest message.
In parallel, I have also worked on a PR (#1370) that should cover most of the points we discussed in this issue.
The issue will be closed once the PR is merged.

Thanks @dreamorosi. I'm so appreciative of how responsive you've been to investigate and improve an already great library, as it does help us to make the case to standardize on using this library to improve our observability, so I am definitely happy about that.
Regarding your investigation, I wonder if you are able to use what you did to recreate the bug I found by also wiring in captureLambdaHandler as a 3rd middleware.
My understanding would be that if you made two or more requests, with the customMiddleware function only throwing an error on the first request, then the 2nd request onwards should throw an error from the Tracer.getSegment() call in captureLambdaHandlerBefore.
If that is the case, I'm hopeful that it may be something that could be passed onto the AWS X-Ray team to easily recreate and investigate on their end as it may be something very simple such as some in-memory state which isn't correct since captureLambdaHandlerBefore wasn't called the first time round.
Obviously for us we've moved the captureLambdaHandler ahead of those middleware functions, so it's not high importance to do this, but I thought it may be worth considering if we now have a simple problem recreation.


UNLINK verb support

When I create LINK request:
fetch("/post", { method: LINK, headers: ... })
It works fine.
But when I try to send UNLINK request:
fetch("/post", { method: UNLINK, headers: ... })
It sends GET request instead.
Is it bug?

Not relevant.
I was using native browser implementation of fetch.


Upgrade android ndk to r23c LTS

RT, benefits:

Full c++17 filesystem support
c++20 support for future

Done by #650


Fix StringView constructor to not fail on a nulll pointer.

[approve ci autest]

Cherry-picked to 7.1.x


Un-negate the names

We have several config options which start with disable as well as some similarly named classes. Using negation in names makes them harder to understand, mainly when get negated once again in an expression like the following.
@BuildStep(onlyIfNot = Flags.MainDisabled.class)

I propose to rename all those to something like quarkus.camel.main-enabled and refactor all as needed. We should do this before 1.0.0.
Please assign to me.

This would be easy to do and I am ready to do that. If somebody wants to veto the proposal please do so sooner rather than later so that I do not waste my time.


2.0109: Garden Info pop-up flickers on hover

It flickers like it's trying to reposition itself and failing.

What version of Cookie Monster are you using?  The reason why I ask is because the beta version of Cookie Monster is outdated and has that problem while the live version does not.

Whatever version is hosted at http://aktanusa.github.io/CookieMonster/CookieMonster.js

Weird, I didn't get a notification, but a new version is out around that time.  Try that out and let me know.  That does seem like the live version you used, in which the problem should have been fixed already.

Still happening. Mac OS X 10.13.6, Safari 11.1.1 (13605.2.8)

Dang, okay.  What's going to make it real hard is that I am on Windows and no way to test on Safari.  Hmm, would it be possible to make a desktop capture video of the problem?

Did it work fine on the older version of CC?  This is not going to be easy ~_~

You know what, never mind, this is broken in CC proper, not just Cookie Monster.

Ah, well at least it's somewhat nice to know it's not CM, lol.


Create Pages “contact”

Automatically generated by Static CMS

👷 Deploy Preview for la-chicharra processing.

Name
Link

🔨 Latest commit
b2778a3cefbc654678c2b2ef9da99234d2cfad2b

🔍 Latest deploy log
https://app.netlify.com/sites/la-chicharra/deploys/662c00f2b4fc400008257b56


Question: alternate protocol support

Could LUNA be extended with other protocol analysis (SPI, I2C,MIPI etc..) using the 16 user defined I/O ports as generic I/O ports and bring those pins to the outside of the enclusure on a header ? This would make LUNA a very lucrative alternative to other $1000+ USB2.0 and multiprotocol analyzers. Not being familair with LUNA yet, suppose this would be grabbing a bunch of samples into the buffer and send them to the host software that for example Sigrok/PulseView or other open source software could analyze ?

We've actually already made the change to bring those I/Os to the outside of the enclosure in the form of two PMOD ports. See this update on CrowdSupply for more info.
It would certainly be possible to enable using those I/Os as a simple logic analyzer in exactly the way you describe. Writing the software and gateware to do that isn't on our priority list at the moment, as we need to focus on the USB features we've committed to, but it would be a fairly straightforward project.

Thank you. That tis really great. A few others question while having difficulties get through the Discord phone verification process (it seems to be locked up somehow) so post them here

Could not find "technial specifications" for LUNA: Curious for what is the internal sample rate ?  Other prduct use 1 to 2GHz (DSLogic/Zeroplus). What would the rate be for the user GPIO and what speed  in/out clockd could be created?

Read that memory is 8MB . Other products support 64~128MB  For USB HS, how many seconds of data could be stored in the buffer or is for HS ? Could memory be expanded  and would streamed transfer an viable option through the USB 3.0 host ?

Curious for what is the internal sample rate ? Other prduct use 1 to 2GHz (DSLogic/Zeroplus). What would the rate be for the user GPIO and what speed in/out clockd could be created?

LUNA doesn't work by sampling the USB data lines directly at high speed, there are USB 2.0 PHYs for each port which are used as the high speed interface.
The FPGA is connected to the ULPI interface of each PHY, which includes an 8-bit parallel data bus. Because of that 8-bit wide bus, the logic for capturing USB packets, buffering them and delivering them to the host only needs to run at 60MHz (8 x 60 = 480Mbit/s).
The simplest way to integrate GPIO capture would be to sample the PMOD I/Os at the 60MHz clock, and add the resulting data to the capture buffer. With a bit more work, they could potentially also be sampled/driven from another clock domain at a higher rate. The ECP5 I/O buffers are limited to 200MHz in / 150MHz out for LVCMOS, but can go up to 400MHz for LVDS. Buffer space and USB throughput for the logic data will be the main limiting factors though, especially if trying to capture USB at the same time.

Read that memory is 8MB . Other products support 64~128MB For USB HS, how many seconds of data could be stored in the buffer or is for HS ? Could memory be expanded and would streamed transfer an viable option through the USB 3.0 host ?

Since we identify and capture USB packets on the FPGA, rather than just raw samples of the data lines, the duration we can store in memory depends on the USB traffic involved. In the most demanding scenario where the bus is fully utilized at HS, an 8MB buffer provides something like ~150ms of capture.
We can stream buffered packets to the host at around 40MB/s, so if the target bus utilization is moderate, or limited to short bursts of high traffic, it is possible to capture indefinitely. Due the overhead involved in streaming a HS capture over HS however, it's not possible to maintain continuous capture if the target bus is more heavily utilized.
It may be possible to achieve unlimited HS capture by a channel bonding approach using both the 'host' and 'sideband' ports for streaming, but this would require two cables to the host which would have to be attached to independent buses. Implementing this is not currently on our roadmap.
The current hardware does not have any support for USB 3.0. There is partial support for USB 3.0 in the LUNA gateware library, but utilising it will require a future product with different hardware.

Thank you much for the explanation.
Ideally that user IO could be used to test MII/RMII/GMII for ethernet, but those are  25, 50 and 150MHz respecitively.
For the USB use case faced is as follows:
1, Using libusb sending a control request frm a host PC to retrieve a interface descriptor from a device does not show anything
going out in wireshark
2. Adding breakpoint in the USB device does not trigger a receipt for such packet
3. The USB device firmware  library creator would like to see "proof" that the request did go over USB before
putting  the library into question.
This the idea was to use an analyzer to captrure if there was a really a transfer on bus:

At Full speed, the buffer might be large enough for several seconds of USB data
For High speed, the only way for longer capture is streaming over USB 3.0 to the host to gather sufficnet data

Approach 1:
A. Put the device in full speed and use a low cost USB analzyer. the reuslt would probably be the same at high speed
B. At high speed use a high cost capture device and a USB 3.0 PC host with sufficient speed to catch up the USB 3,0 data
So here is why LUNA came in as a low cost option for HS. The only question now is if the USB PC host is fast enough.
Please corretct me if this way of thought is incorrect or if there is better approach

The other way around the USB 2.0 bottleneck is to do some packet filtering on the FPGA, to exclude things that aren't of interest. E.g. you could discard all traffic that's not on endpoint 0, which would keep the data rate down whilst still ensuring that you see the transfer you're looking for if it's there.
At the moment we don't have frontend features for doing that, but with our Amaranth workflow, an ad-hoc hack to add a filter on the FPGA side can be as simple as editing luna/gateware/usb/analyzer.py and re-running things.

That is a great feature for custom code for data manipulation and triggering. Looking at the schematic, the upstream USB is high speed. Even the ULPI runs at 60MHz,  all the data has to be moved upstream again to the host (PC).  if that is uncompressed the data amount would be about 1:1 (if not more if there is some overhead such as meta data), correct ?
Since the FPA need to cope with the "slow" upstream USB 2.0 ULPI interface, Would that not cause  congestion in the FPGA ?
In other words, were there any considerationto us an USB3.0 tranceiver instead that could reduce risk for such bottlenecks for streaming data to the host (PC) ? The FPGA would need to add functionality to interfae to such an USB 3.0 device controller.
Key question: Have any experiments been done if the USB HS streaming to the PC host can sustained over longer periods, say 5 to 10 seconds ?

We're using the LUNA stack in Orbtrace, and I can share some performance numbers from our testing.
First of all, the theoretical max HS USB bulk capacity is 13 packets per microframe, and at 512B per packet and 8000 microframes per second, that comes out to 425.984 Mb/s (53.248 MB/s). We have however not been able to reach this in our testing, probably due to practical limitations with the host side scheduling and reserved capacity for other devices on the bus.
We've however been able to reach 12 packets per microframe which comes out to around 393 Mb/s (49 MB/s), and can sustain this as long as there's not a lot of other traffic on the bus fighting for capacity. We're doing this with only 8kB+1kB of buffering on the device side.
I figure more buffering is mainly useful if you've got bursty traffic with a reasonably large difference between peak and average data rates.

Overhead depends somewhat on the nature of the traffic but let's work through a simple high-throughput case - capturing a single target device making one continuous flat-out bulk IN transfer with full 512 byte packets. Assume for the sake of simplicity that we're filtering out SOF packets and other traffic, and that nothing gets NAKed.
In that scenario, for each 512 bytes of payload data sent by the target device, LUNA will currently put 525 bytes into the capture buffer for the IN transaction:

2 bytes length header + 3 bytes IN packet
2 bytes length header + 3 bytes DATA0/1 packet fields + 512 bytes payload
2 bytes length header + 1 byte ACK packet

As @zyp notes, the realistic limit for one device is 12 of those transactions per microframe and there are 8000 microframes per second, so LUNA has to buffer 12 * 8000 * 525 B/s for a total of 50.4MB/s, and could stream that buffer to the host at 12 * 8000 * 512 B/s or 49.152MB/s. So the buffer would fill up at (50.4 - 49.152) = 1.248MB/s. With an 8MiB buffer that would correspond to 6.72s of capture time. But if we can compress the buffered data on the FPGA side by even just 3%, then it becomes possible to capture indefinitely.
In most practical scenarios, HS throughput to the host should be sufficient to get things done, especially when combined with all the filtering and triggering logic that's possible through customising the analyzer gateware. Adding a USB 3.0 transceiver would have significantly increased the cost of the device. For scenarios where you really want to capture every detail of a completely saturated bus, there's always the possibility of using the second USB 2.0 port to increase throughput.

6 seconds would be more than enough to gather data. Looking at the schematic, the USB3343 is used.  Does LUNA support USB Low/full speed as well  . It would require to get the USB data, but not via ULPI,correct ?

Yes, low and full speed capture are supported. At the moment you have to select which speed you want to capture, but on-the-fly speed detection is on the todo list.


Make sure all CMake files are included

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

This ensures all CMake files are included, overwriting those from cpp-opentelemetry-api since this package includes additional definitions.

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

Selectors are suggested to take a <two spaces>#<one space>[<expression>] form. See lines [14, 15]

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Single VM: Bugfix: Setup the cloud-init in the right location

Setup the cloud-init in the controller data directory vs the cache.
Fixes https://github.com/01org/ciao/issues/925
Signed-off-by: Manohar Castelino<EMAIL_ADDRESS>

Coverage increased (+0.02%) to 64.757% when pulling 66ae1225fd94715013419902f615745e8c535159 on mcastelino:topic/singlevm_fix_test_ips into f107ee0ef9310d263b36419555176f07435b8b0e on 01org:master.


Revert "Revert "Balder/fix logic flaw causing missing config changes""

Reverts vespa-engine/vespa#4275

Superceeded by #4367


Flake error B031 caused by new release flake8-bugbear

Using flake8-bugbear-23.1.20 the pre-commit hook passed. Once flake8-bugbear-23.2.13 was released the flake8 step of the pre-commit hook started to fail with
scripts/generate_identifier_pattern.py:33:18: B031 Using the generator returned from `itertools.groupby()` more than once will do nothing on the second usage. Save the result to a list, if the result is needed multiple times.

Fixed in the 3.1.x branch, I just need to merge it forward. https://github.com/pallets/jinja/commit/be0bcb61f9e2918c85cbe0ccb04e1d7b36c68a70


can the custom select box be hidden via an option?

Thanks for opening the issue. We're sorry to say that we've stopped maintaining this project in favor of angular-mighty-datepicker. We encourage you to check it out instead.


Governance metadata is not validated

Description
There is no metadata validation for the governance metadata. Right now is possible to submit a governance action with wrong metadata/missing required fields and the only time we can see an error is when dbsync try to catch the data.
Steps to Reproduce
e.g.

run cardano-cli conway governance drep metadata-hash --drep-metadata-file drep_metadata.json
drep_metadata.json    -> missing givenName that is marked as Compulsory in cip-0119
No error is returned

Additional Context
CIPs related to governance metadata:
https://github.com/cardano-foundation/CIPs/tree/master/CIP-0100
https://github.com/cardano-foundation/CIPs/tree/master/CIP-0108
https://github.com/cardano-foundation/CIPs/tree/master/CIP-0119

In case cli plans to support this, we have implemented metadata parsers following the above cips https://github.com/IntersectMBO/cardano-db-sync/blob/master/cardano-db-sync/src/Cardano/DbSync/OffChain/Vote/Types.hs

cardano-signer is doing checks if a metadata file is valid, also checks about the signatures.


Megafilter doesn't work on lenses

When used in a lens, the refresh moves the url back to the base resource.
Steps to reproduce:

Create user lens
Add lens to user resource
Add MegaFilter to lens
Attempt to check/uncheck any column
Router moves to original resource (i.e. resources/users/ from resources/users/lens/user-verification)

Have you had any luck fixing this issue? Im running into the same issue

The same issue!


fix username updater 2

Make getuser async so that getpersonasync can be awaited and exception can be caught.
Should actually fix PockyBot's separation anxiety this time.

:tada: This PR is included in version 1.15.3 :tada:
The release is available on:

v1.15.3
GitHub release

Your semantic-release bot :package::rocket:


[helmignore] Support for '!' as a special leading sequence

.helmignore has "supported" negative matches uselessly for a long time, reported as an open ticket (https://github.com/helm/helm/issues/3622) as early as 2018. This revision implements negative matching correctly and usefully for the first time.
Closes #3622.
If applicable:

[x] this PR contains documentation
[ ] this PR contains unit tests
[ ] this PR has been tested for backwards compatibility

Hi @taliastocks! Sorry for not seeing this sooner.
Would you mind writing unit tests covering these changes? This seems like something we can a test suite to check against expected input/outputs. That way we can also check against existing .hemlignores to ensure we're not accidentally breaking some charts.

Hi @bacongobbler,
Thanks for taking a look at this. As it stands, I unfortunately can't dedicate more time to this, as it's no longer a blocker for my team (not to mention, I'm about to be on leave for three months...). We've instead opted to use the .Files API to solve our original problem.
That said, if there's anyone in the community who would like to take this work from here, please feel free to commandeer. A couple notes that might come in handy, copied from my post to the bug report thread:

I think we can avoid breaking most compatibility due to the fact that this feature, as written, is nearly useless:

As written, all rules must match /Chart.yaml, otherwise the helm chart stops working entirely.
This means, more or less, that the only useful negative rule is !*.yaml.

To maintain most backwards compatibility, we could treat a set of rules that, aside from directory rules, only contain negatives as implicitly including * as a positive rule:

!*.yaml would continue to exclude all non-yaml files when included on its own in a .helmignore.
Directory rules would continue to work as-is due to the above exception, and files in these directories would not be included because excluded directories are not traversed.

This isn't perfect, however, because some users may currently include redundant positive rules alongside !*.yaml, for example README.md. The presence of these rules doesn't currently add anything to the !*.yaml negative rule, but nonetheless they may appear in the wild.

Note that not all of the above backwards compatibility is implemented yet in this branch -- only the standard .gitignore behavior.
Regards,
Talia

Hey, I just hit this as well.  I'm looking to use https://ko.build/ to build images in our helm chart by running something like the following:
rm templates/combined.yaml; ko resolve --base-import-paths -f templates/ > templates/combined.yaml

And then have helm ignore all the files except combined.yaml.  This sorta works (you need to finesse ko's YAML parser for helm templates), but the simple .helmignore you'd want to write ends up excluding Chart.yaml:
!templates/combined.yaml
templates/*.yaml

Even worse, it appears that combining two negative patterns limits the included files to only those that match both patterns.

@taliastocks Could you please rebase?

This is 2 years old, but https://github.com/helm/helm/pull/12265 might be a suitable replacement if you'd like to look at it


feat: add UpdateRegistry msg for gov proposal to update the token registry

Description
closes: #1001
Sample proposal.json for submit the proposal from gov

Note : creator address will be the gov module address

{
    "messages": [
        {
            "@type": "/umee.leverage.v1.MsgUpdateRegistry",
            "creator": "umee10d07y265gmmuvt4z0w9aw880jnsr700jg5w6jp",
            "title": "Update the Leverage Token Registry",
            "description": "Update the uumee token in the leverage registry.",
            "registry": [
                {
                    "base_denom": "uumee",
                    "reserve_factor": "0.100000000000000000",
                    "collateral_weight": "0.050000000000000000",
                    "liquidation_threshold": "0.050000000000000000",
                    "base_borrow_rate": "0.020000000000000000",
                    "kink_borrow_rate": "0.200000000000000000",
                    "max_borrow_rate": "1.500000000000000000",
                    "kink_utilization": "0.200000000000000000",
                    "liquidation_incentive": "0.100000000000000000",
                    "symbol_denom": "UMEE",
                    "exponent": 6,
                    "enable_msg_supply": true,
                    "enable_msg_borrow": true,
                    "blacklist": false,
                    "max_collateral_share": "0.900000000000000000",
                    "max_supply_utilization": "0.900000000000000000",
                    "min_collateral_liquidity": "0.900000000000000000",
                    "max_supply": "123123"
                }
            ]
        }
    ],
    "metadata": "AQ==",
    "deposit": "100uumee"
}

Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...

[ ] included the correct type prefix in the PR title
[ ] added ! to the type prefix if API or client breaking change
[ ] added appropriate labels to the PR
[ ] targeted the correct branch (see PR Targeting)
[ ] provided a link to the relevant issue or specification
[ ] added a changelog entry to CHANGELOG.md
[ ] included comments for documenting Go code
[ ] updated the relevant documentation or specification
[ ] reviewed "Files changed" and left comments if necessary
[ ] confirmed all CI checks have passed

Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...

[ ] confirmed the correct type prefix in the PR title
[ ] confirmed all author checklist items have been addressed
[ ] reviewed state machine logic
[ ] reviewed API design and naming
[ ] reviewed documentation is accurate
[ ] reviewed tests and test coverage
[ ] manually tested (if applicable)

@robert-zaremba  should we remove NewCmdSubmitUpdateRegistryProposal from tx.go in leverage module and gov proposal handler from app.go ?

@robert-zaremba should we remove NewCmdSubmitUpdateRegistryProposal from tx.go in leverage module and gov proposal handler from app.go ?

The old proposal type can be removed in this PR, since we're adding the new one.

@robert-zaremba should we remove NewCmdSubmitUpdateRegistryProposal from tx.go in leverage module and gov proposal handler from app.go ?

The old proposal type can be removed in this PR, since we're adding the new one.

Ok

Could we make x/leverage follow the pattern seen elsewhere in the sdk, with
// GetAuthority returns the x/leverage module's authority.
func (k Keeper) GetAuthority() string {
	return k.authority
}

with k.authority set to authtypes.NewModuleAddress(govtypes.ModuleName).String()?
Similarly, MsgUpdateRegistry field Creator can be renamed to Authority and any mismatch should be rejected with err "expected gov account as only signer for proposal message"
See x/bank example

I updated the changes with authority

should we remove NewCmdSubmitUpdateRegistryProposal ...

Yes

If you could

document somewhere a an example CLI for creating this proposal type (possibly add it to the leverage spec or readme)
and run a local test to make sure it executes as expected

then I think we can merge this

@robert-zaremba  @toteki  now I moved addTokens to MsgAddTokensToRegistry message from updateRegistry , so now updateRegistry only do update the token setttings and addTokensRegistry only add tokens to registry

Following this comment on a separate PR, could we rename
MsgAddTokensToRegistry -> MsgGovRegisterTokens
and
MsgUpdateRegistry -> MsgGovUpdateRegistry
?


Force doxygen install to be version 1.9.6

This makes the version deterministic and allows the installation of versions that might not be available via apt-get.
Closes #29

Maybe the version number could be made an input variable so the user can choose the version and it could default to a specific version. What do you think?

@DenverCoder1 - I did think about that, I can modify the PR. give me a second.

@DenverCoder1 - don't merge this. Making this a parameter is more fiddly. Leave it with me.

@DenverCoder1 - so I have made the changes to make this a parameter.
Note - in my testing, I discovered that this approach only works for versions 1.9.3 and higher. Previously this action was defaulting to 1.9.1. So this might be considered a breaking change. That is your call though.

Do you know there are significant differences between 1.9.1 and 1.9.6? If for most people, it shouldn't make a difference, it should be fine to make this a breaking change.

There are no breaking changes according to their changelog. My code works with 1.9.1-1.12.0. I just need a capability they added in 1.9.6.

@DenverCoder1 - is there anything more you want me to do on this?

I will test and this should be good :+1:


Add timeout to scripted statements

Sometimes scripted tasks hang in ci and they are effectively impossible
to debug. To workaround this, I add a five minute timeout to any
scripted test and print the log if the test fails.

[error] /home/travis/build/sbt/sbt/scripted-sbt-redux/src/main/scala/sbt/scriptedtest/BatchScriptRunner.scala:72:15: not found: type TimeoutException
[error]       case e: TimeoutException => throw new TestException(statement, "Command timed out", e)
[error]               ^
[error] one error found

Whoops. Squashing error.


Windows Mixed Reality platform configuration is missing its Boundary Profile

XRTK - Mixed Reality Toolkit Bug Report
Describe the bug
When the Mixed Reality configuration is automatically loaded into a project, it is missing the Boundary configuration
To Reproduce
Add WMR to a new XRTK project.
Examine the Boundary configuration and note the WMR boundary is missing in the list of providers
Expected behavior
WMR Boundary configuration should be deployed
Actual behavior
It isn't

Duplicate of https://github.com/XRTK/WindowsMixedReality/issues/113


Specify nonces for feePayer and zkApp to allow multiple tx in a block

Need to track these offline, but can then sign and broadcast the transactions and include multiple in a block e.g. https://github.com/garethtdavies/zkAppPool/blob/main/batch-signed-tx.ts#L96

Only need the feePayer as zkApp incrementNonce is False.

As the index is checking against an on-chain state variable, this is limited to 1 per block.

Added fee payer nonce via #22

Hopefully closed by #23


Schema Registry authorization

Add documentation on Karapace Schema Registry authorization.

Thanks for bringing this! I will admit that I'm confused so far though, do you think we could see some examples of changing the ACLs for both the REST API and the schema registry? And perhaps some information about what happens if access is denied in either of those contexts. Also is this feature so that a user who can't access the schema for a message shouldn't be able to access the message, is that the idea? I think we should explain what this is for as well, if there are one or two clear problems it solves.

do you think we could see some examples of changing the ACLs for both the REST API and the schema registry?

I added an example how to add an ACL entry in this PR. This is for Schema Registry only, REST API authz we don't have yet.

And perhaps some information about what happens if access is denied in either of those contexts.

Added explanation of the error code.

Also is this feature so that a user who can't access the schema for a message shouldn't be able to access the message, is that the idea? I think we should explain what this is for as well, if there are one or two clear problems it solves.

I'm not sure if I'm following. The Kafka topic ACL controls access to messages themselves in Kafka. Schema Registry ACL controls the access to the schemas etc stored in Schema Registry. So these are related, but not connected. Both ACLs are managed separately.

Thanks @juha-aiven for the contribution, I'm currently reorganising the content to follow the devportal structure, I'll push a commit soon with the new org and then I'll tag you for more details to the sections I feel missing

I believe this is ready to be reviewed, since I've been involved a lot I would hope to have an external reviewer.
I'm a bit concerned that the Karapace endpoints are not well explained, but that might be a joint effort between devportal and karapace docs. But mainly we can tackle it as with an additional PR and have this initial PR go live in devportal as it it since the feature should go live soon


Added Anastasiia (my wife :)).

Merge conflict was fixed.

Awesome, thank you @Matroskeen!
merged #1


mpu.exe with mono on OSX: System.Exception: Compiler failed to produce the assembly. Output: ''

I'm getting some undefinable errors when trying to generate a serializer for an extremely trivial enum, using OSX. Going to try on Windows later.
The command I'm using is
mono mpu.exe -s /Users/xxxx/Desktop/mpack/xxxx.cs
Full error log:
System.Exception: Compiler failed to produce the assembly. Output: ''
  at Mono.CSharp.CSharpCodeCompiler.CompileFromFileBatch (System.CodeDom.Compiler.CompilerParameters options, System.String[] fileNames) [0x00000] in <filename unknown>:0
  at Mono.CSharp.CSharpCodeCompiler.CompileAssemblyFromFileBatch (System.CodeDom.Compiler.CompilerParameters options, System.String[] fileNames) [0x00000] in <filename unknown>:0
  at System.CodeDom.Compiler.CodeDomProvider.CompileAssemblyFromFile (System.CodeDom.Compiler.CompilerParameters options, System.String[] fileNames) [0x00000] in <filename unknown>:0
  at mpu.SerializerTargetCompiler.CompileSourceFiles (IEnumerable`1 sourceFilePathes, IEnumerable`1 referenceAssemblies, System.IO.TextWriter outputWriter, mpu.ColorizedTextWriter errorWriter) [0x00000] in <filename unknown>:0
  at mpu.SerializerTargetCompiler.CompileTargetTypeAssembly (IEnumerable`1 sourceFilePathes, IEnumerable`1 referenceAssemblies) [0x00000] in <filename unknown>:0
  at mpu.Program.GenerateSerializers (IList`1 sourceFilePathes, System.String[] referenceAssemblies, Boolean sourceFileIsAssembly, System.String includingPattern, System.String excludingPattern, Boolean treatWarningsAsErrors, Int32 warningLevel, MsgPack.Serialization.SerializerCodeGenerationConfiguration configuration) [0x00000] in <filename unknown>:0
  at mpu.Program.Execute (IEnumerable`1 args) [0x00000] in <filename unknown>:0
  at mpu.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0

EDIT: Works just fine on Windows. Probably some mono bug?

Sorry for delay.I cannot repro it with Mono 4.0.3 in MacOS X. Please retry it with latest mpu.exe and mono.

Close because this was not reproduced and no additional post... Please reopen when you face this problem again.

i have faced this problem again...

Would you tell me the mono version?

I have fixed it,  this problem appeared because i have used "Class a" extends "Class b", and i serialize a but not serialize b, sorry to disturb you.

No problem!

Close this because it was not a msgpack issue.


Destination Window

https://github.com/DCAN-Labs/file-mapper/tree/aa21eb5dce3867ea939261fc872501e79481182f
File Mapper Gui was functional at this commit.
Create new window in the GUI that gets the user to provide a destination argument for making either an absolute path or relative path to the desired destination.

Hi @raguramvv - we do not plan on supporting the file-mapper GUI moving forward, unfortunately! I am going to close this issue as not planned.