Consider using Content-Length instead of chunked encoding

Use of chunked encoding is unnecessary and does not result in the best performance on normal JSON/text payloads. We should consider computing a payload length and using Content-Length instead. This requires some changes to our tests that assume chunked encoding.

From BareResponseImpl:
        if (keepAlive) {
            if (status.code() != Http.Status.NO_CONTENT_204.code()) {
                HttpUtil.setTransferEncodingChunked(response, true);
            }
            // Add keep alive header as per:
            // - http://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-01.html#Connection
            response.headers().set(HttpHeaderNames.CONNECTION, HttpHeaderValues.KEEP_ALIVE);
        }

@romain-grecourt Can you elaborate on your comment? :)

Just highlighted the code current code in Helidon that activates transfer encoding.
Also from the netty javadocs:

maxChunkSize
The maximum length of the content or each chunk. If the content length exceeds this value, the transfer encoding of the decoded response will be converted to 'chunked' and the content will be split into multiple HttpContents. If the transfer encoding of the HTTP response is 'chunked' already, each chunk will be split into smaller chunks if the length of the chunk exceeds this value.

Seems that we'd have to tune maxChunkSize according to the content length.
Thinking-out-loud: Given that the payload is consumed by BareResponseImpl with a subscriber there is no easy way to get the content-length right ? Maybe the subscriber could accumulate the data-chunks until onComplete so that the content-length can be computed.
I presume that this would have to be optional and configureable on the response, maybe the media support class can do that at the same time it registers the reader/writer but that is without knowing the actual payload. Maybe we could event go further and give that ability to the writer since it converts the entity to Publisher<DataChunk> so it may have a way to derive the content-length early.
Maybe we could also think of a "buffer until threshold" mechanism in the response.  I.e Accumulate at most N bytes to achieve content-length, otherwise do chunked.

Chunked encoding exists for cases when payload size is unknown.
You do not need to limit "content-length" responses by size - even a 1GB file can be sent without chunked encoding, as long as you know the size in advance.
Usually the decision is done based on the presence of Content-Length header being set by the user (or in our cases we could do it also when user sends String, JsonObject and other objects that are in-memory already and we can easily transform them into bytes and measure the size).

Our underlying implementation is reactive so we'd have to implement something that does not rely on the entity, otherwise this means we'd have to carry that information from the media writer down to BareResponseImpl.
Having a buffer until threshold mechanism, similar to what's described on the Netty javadocs seems viable.

PR #773
PR #783
PR #795


opentracing-contrib / csharp-netcore -> warrenbrasil / open-tracing-contrib

Closed this PR because it was totally out of date.


Contributions

do u expect contributions on this repo or is this just for sharing code u wrote in ur videos?

This isn't the repo the live bot uses though

y is that?

There's some additional things, mainly database access, that fell outside the scope of this project, but we're needed for a public bot at the scale everyone wanted.


How to use with Docusaurus?

I would like to use this plugin with Docusaurus, specifically, as an MDX plugin.
IIUC, this is not possible because Docusaurus doesn't have ESM support. Is this right? Or is there a way around that?

Turns out Docusaurus describes how to do it.
I can confirm that this works:
const inlineSVG = (await import('remark-inline-svg')).default;

Plus using it like this:
docs: {
  // ...
  beforeDefaultRemarkPlugins: [inlineSVG],
}

I just haven't figured out how to adapt the options.

After adding some console.log debugging statement, I am believing that option passing is buggy in Docusaurus. I was able to work around it though.
Now I'm faced with the next issue, which is path resolution. While the plugin works successfully for SVGs in the same directory as the source file, it fails when the URL is relative to the root. Consider this snippet:
  return async (tree, file) => {
    const svgs = [];

    const markdownFileDir = dirname(file.history[0]);

    visit(tree, 'image', (node) => {
      const { url } = node;

      if (url.endsWith(suffix)) {
        // Debugging here....
        console.log(url);
        console.log(markdownFileDir);

This prints:
/img/actor-distribution.svg
.../web/docs/understand/architecture

The second line is the location of the Markdown file, whereas the first line is the image relative to static image directory .../web/static/.
Any ideas how to make this work?
(Sorry for the noob'ish style of unrolling this, my frontend fu is rather limited.)

Hey Matthias,
Thank you so much for updating your comments with solutions!
Can you try updating tov1.1.0? I think I found a fix

Thanks for shipping a fix! Unfortunately, it didn't work for me:
$ docusaurus start
[INFO] Starting the development server...
[SUCCESS] Docusaurus website is running at: http://localhost:3000/

✖ Client
  Compiled with some errors in 3.18s

Error: ENOENT: no such file or directory, open '/Users/mavam/code/tenzir/vast-docs/web/img/actor-distribution.svg'
client (webpack 5.74.0) compiled with 1 error

There are three paths involved here:

The web "root" at /Users/mavam/code/tenzir/vast-docs/web/
/img/actor-distribution.svg: the location of static images, relative to the project root
The path to the Markdown file within the web root: docs/...

A bit more context. In the Markdown file located in docs/..., I include the image as follows:
![Actor Distribution](/img/actor-distribution.svg)

Is there perhaps some missing piece that tells remark where to look for files that start with /? Is this a Docusaurus thing?
Grand context: I am working on https://vast.io/docs/understand/architecture/actor-model. I want to replace all PNGs with inlined SVGs with your plugin, so that I get the right fonts in the SVG to show and can stop the export-twice-for-dark-and-light-mode madness and finally use CSS.


OTP challenge-response fails with timeout

The following program fails with a timeout with my recently bought Yubikey 4. HMAC-SHA1 challenge-response works fine.
import sys
import yubico

# Look for and initialize the YubiKey
try:
    YK = yubico.find_yubikey()
    # Do challenge-response
    secret = b'Sample'
    print("Sending challenge : %s\n" % repr(secret))

    response = YK.challenge_response(secret, mode="OTP", slot=1)
except yubico.yubico_exception.YubicoError as inst:
    print("ERROR: %s" % inst.reason)
    sys.exit(1)

print("Response :\n%s\n" % yubico.yubico_util.hexdump(response))

Nevermind, it's actually an issue with the configuration tool, which showed only "HMAC-SHA1" until I upgraded it.


Wildcard support, please

I am using CaptainRov and I need to use wildcards for my tunnel domain on boringproxy but I get "Failed to get cert".
E.G. *.example.com
Can this be done?
Also If I have.
test.example.com at port 80,
I can't do test.com:3000
"Tunnel exists for domain"

In ACMEv2 Wildcard certificates need support for DNS-01 challenges.
This is supported by the upstream library
https://github.com/mholt/acmez and needs to be passed additional
configuration.
Please note that the logic to provide the challenge is not
implemented, and needs to be built from scratch.

The acmez package is "bring-your-own-solver." It provides helper utilities for http-01, dns-01, and tls-alpn-01 challenges, but does not actually solve them for you. You must write an implementation of acmez.Solver in order to get certificates. How this is done depends on the environment in which you're using this code.

That in return means one has to implement or use a specific or generic
DNS API provider to be able to confirm the challenge.
The Lego library has both built in. https://go-acme.github.io/lego/
On Mon, 9 Nov 2020 at 18:29, voarsh2<EMAIL_ADDRESS>wrote:

I am using CaptainRov and I need to use wildcards for my tunnel domain on boringproxy but I get "Failed to get cert".
E.G. *.example.com
Can this be done?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Thanks @almereyda.
@voarsh2, wildcards could potentially be implemented in the future, but as @almereyda mentioned it requires using the DNS challenge. However, I'm already planning to integrate DNS functionality because I want to automate other functionality, so once that's in place this might be fairly easy to add. I'm going to mark it as an enhancement and leave the issue open, but it's still a maybe at this point.

@voarsh2, wildcards could potentially be implemented in the future, but as @almereyda mentioned it requires using the DNS challenge. However, I'm already planning to integrate DNS functionality because I want to automate other functionality, so once that's in place this might be fairly easy to add. I'm going to mark it as an enhancement and leave the issue open, but it's still a maybe at this point.

Sure, I understand.
It's just many "homelabs" use wildcards, some won't even let you use the software/install something because they do a url "check" using a wildcard URL, which can't be done on boringproxy.
Any thoughts on multi ports on the same URL?
In the meantime, has anyone come across a wildcard support alternative to boring proxy (albeit harder to setup)?

You could use PageKite and do the TLS offloading, hence certificate
generation at the end of the tunnel, locally. Then you're free to use
whichever reverse proxy and certificate generation method suits you best.
On Tue, 10 Nov 2020 at 14:26, voarsh2<EMAIL_ADDRESS>wrote:

@voarsh2 https://github.com/voarsh2, wildcards could potentially be
implemented in the future, but as @almereyda
https://github.com/almereyda mentioned it requires using the DNS
challenge. However, I'm already planning to integrate DNS functionality
because I want to automate other functionality, so once that's in place
this might be fairly easy to add. I'm going to mark it as an enhancement
and leave the issue open, but it's still a maybe at this point.
Sure, I understand.
It's just many "homelabs" use wildcards, some won't even let you use the
software/install something because they do a url "check" using a wildcard
URL, which can't be done on boringproxy.
Any thoughts on multi ports on the same URL?
In the meantime, has anyone come across a wildcard support alternative to
boring proxy (albeit harder to setup)?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/boringproxy/boringproxy/issues/15#issuecomment-724700272,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAMRV7GWNRZC32U36MBFOL3SPE5P7ANCNFSM4TPUQ6NQ
.

I'm actually planning to add LetsEncrypt support directly to the client and implement server TLS passthrough (ie a simple SNI proxy), which would enable us to do end-to-end encryption. This would be similar to ngrok TLS tunnels but with auto certs from LetsEncrypt (also maybe sounds similar to PageKite, which @almereyda mentioned?). In that case I believe allowing wildcard routing would be useful even without implementing the DNS challenge within boringproxy. @voarsh2 do you know if this would solve your problem with the specific software you're using?

@voarsh2 do you know if this would solve your problem with the specific software you're using?

I couldn't say for sure, but seems to sound like it would.

@voarsh2 do you know if this would solve your problem with the specific software you're using?

I couldn't say for sure, but seems to sound like it would.

Note it may be possible to avoid the dns-01 challenge by automatically getting certs on first connection for a given subdomain. If we limit it to a reasonable number of subdomains per wildcard that should mitigate DoS issues.

I got this idea from certmagic, which may be able to do all the heavy lifting for us:
https://github.com/caddyserver/certmagic#on-demand-tls

For those stucking on this topic and until a nice out-of-the-box solution will be provided by BoringProxy, I recommand this well documented solution:
DISCLAIMER: very techy one
https://github.com/mochman/Bypass_CGNAT

Hi @anderspitman,
I hope your holidays were funny and restful. ;-)
Did you have some time to elaborate a bit your ideas about certmagic's TLS on demand?

Hi,
Is this project dead? Is this feature coming anytime soon?

No, it's oss. It'll live.
On Mon, Sep 18, 2023, 11:26 PM Gandalf-the-Blue @.***>
wrote:

Hi,
Is this project dead? Is this feature coming anytime soon?
—
Reply to this email directly, view it on GitHub
https://github.com/boringproxy/boringproxy/issues/15#issuecomment-1724049025,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIUGWACFECWYF4MN6ZDNAX3X3B743ANCNFSM4TPUQ6NQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Using Go ?
On Tue, Sep 19, 2023, 1:33 AM Anders Pitman @.***>
wrote:

I'd say more maintenance mode currently than dead. I'm still working on
closely related projects (not released yet) which will eventually include
more features like this, but boringproxy itself is unlikely to implement
new features.
—
Reply to this email directly, view it on GitHub
https://github.com/boringproxy/boringproxy/issues/15#issuecomment-1724248829,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIUGWAE5J6QTMFBYEXQ4UVDX3COXTANCNFSM4TPUQ6NQ
.
You are receiving this because you commented.Message ID:
@.***>


Gitleaks fails to run on ubuntu wsl with UrlError

Describe the bug
The pre-commit script for gitleaks is failing during commits with the error below
An unexpected error has occurred: URLError: <urlopen error [WinError 10061] No connection could be made because the target machine actively refused it
To Reproduce
pipenv install --dev pre-commit
pre-commit install
pre-commit autoupdate
git add .
git commit -m "updates to test gitleaks"
Expected behavior
I expected to see the report for gitleaks detailing the hardcoded credentials in my repo

Screenshots

Basic Info (please complete the following information):

OS: Ubuntu on WSL
Gitleaks Version: v8.16.1, v8.16.3

Additional context
logs generated by pre-commit:
Logs

version information
pre-commit version: 3.2.2
git --version: git version 2.39.0.windows.2
sys.version:
    3.11.1 (tags/v3.11.1:a7a450f, Dec  6 2022, 19:58:39) [MSC v.1934 64 bit (AMD64)]
sys.executable: C:\Users\USER\.virtualenvs\app-UTkeMofs\Scripts\python.exe
os.name: nt
sys.platform: win32

error information
An unexpected error has occurred: URLError: <urlopen error [WinError 10061] No connection could be made because the target machine actively refused it>

Traceback (most recent call last):
  File "C:\Users\USER\AppData\Local\Programs\Python\Python311\Lib\urllib\request.py", line 1348, in do_open
    h.request(req.get_method(), req.selector, req.data, headers,
  File "C:\Users\USER\AppData\Local\Programs\Python\Python311\Lib\http\client.py", line 1282, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File "C:\Users\USER\AppData\Local\Programs\Python\Python311\Lib\http\client.py", line 1328, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File "C:\Users\USER\AppData\Local\Programs\Python\Python311\Lib\http\client.py", line 1277, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "C:\Users\USER\AppData\Local\Programs\Python\Python311\Lib\http\client.py", line 1037, in _send_output
    self.send(msg)
  File "C:\Users\USER\AppData\Local\Programs\Python\Python311\Lib\http\client.py", line 975, in send
    self.connect()
  File "C:\Users\USER\AppData\Local\Programs\Python\Python311\Lib\http\client.py", line 1447, in connect
    super().connect()
  File "C:\Users\USER\AppData\Local\Programs\Python\Python311\Lib\http\client.py", line 941, in connect
    self.sock = self._create_connection(
                ^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\USER\AppData\Local\Programs\Python\Python311\Lib\socket.py", line 851, in create_connection
    raise exceptions[0]
  File "C:\Users\USER\AppData\Local\Programs\Python\Python311\Lib\socket.py", line 836, in create_connection
    sock.connect(sa)
ConnectionRefusedError: [WinError 10061] No connection could be made because the target machine actively refused it

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\USER\.virtualenvs\app-UTkeMofs\Lib\site-packages\pre_commit\error_handler.py", line 73, in error_handler
    yield
  File "C:\Users\USER\.virtualenvs\app-UTkeMofs\Lib\site-packages\pre_commit\main.py", line 381, in main
    return hook_impl(
           ^^^^^^^^^^
  File "C:\Users\USER\.virtualenvs\app-UTkeMofs\Lib\site-packages\pre_commit\commands\hook_impl.py", line 271, in hook_impl
    return retv | run(config, store, ns)
                  ^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\USER\.virtualenvs\app-UTkeMofs\Lib\site-packages\pre_commit\commands\run.py", line 442, in run
    install_hook_envs(to_install, store)
  File "C:\Users\USER\.virtualenvs\app-UTkeMofs\Lib\site-packages\pre_commit\repository.py", line 248, in install_hook_envs
    _hook_install(hook)
  File "C:\Users\USER\.virtualenvs\app-UTkeMofs\Lib\site-packages\pre_commit\repository.py", line 95, in _hook_install
    lang.install_environment(
  File "C:\Users\USER\.virtualenvs\app-UTkeMofs\Lib\site-packages\pre_commit\languages\golang.py", line 137, in install_environment
    _install_go(version, env_dir)
  File "C:\Users\USER\.virtualenvs\app-UTkeMofs\Lib\site-packages\pre_commit\languages\golang.py", line 103, in _install_go
    resp = urllib.request.urlopen(_get_url(version))
                                  ^^^^^^^^^^^^^^^^^
  File "C:\Users\USER\.virtualenvs\app-UTkeMofs\Lib\site-packages\pre_commit\languages\golang.py", line 97, in _get_url
    version = _infer_go_version(version)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\USER\.virtualenvs\app-UTkeMofs\Lib\site-packages\pre_commit\languages\golang.py", line 90, in _infer_go_version
    resp = urllib.request.urlopen('https://go.dev/dl/?mode=json')
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\USER\AppData\Local\Programs\Python\Python311\Lib\urllib\request.py", line 216, in urlopen
    return opener.open(url, data, timeout)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\USER\AppData\Local\Programs\Python\Python311\Lib\urllib\request.py", line 519, in open
    response = self._open(req, data)
               ^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\USER\AppData\Local\Programs\Python\Python311\Lib\urllib\request.py", line 536, in _open
    result = self._call_chain(self.handle_open, protocol, protocol +
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\USER\AppData\Local\Programs\Python\Python311\Lib\urllib\request.py", line 496, in _call_chain
    result = func(*args)
             ^^^^^^^^^^^
  File "C:\Users\USER\AppData\Local\Programs\Python\Python311\Lib\urllib\request.py", line 1391, in https_open
    return self.do_open(http.client.HTTPSConnection, req,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\USER\AppData\Local\Programs\Python\Python311\Lib\urllib\request.py", line 1351, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [WinError 10061] No connection could be made because the target machine actively refused it>

cc @zricethezav

Nope, I am wfh using my PC and on the public internet of GLO
On Thu, Apr 20, 2023 at 3:43 PM Richard Gomez @.***>
wrote:

Is this by chance behind a corporate proxy?
—
Reply to this email directly, view it on GitHub
https://github.com/gitleaks/gitleaks/issues/1157#issuecomment-1516556883,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACIB3UJTCZJ36FRNYLZJQ6TXCFKRRANCNFSM6AAAAAAXFV6CBM
.
You are receiving this because you authored the thread.Message ID:
@.***>

This is a pre-commit specific error. I don't have a solution but maybe someone in the community does. Thanks for trying to reproduce, @rgmz

Alright, thanks but I should note that other hooks are running after I
commented out the gitleaks entry from my pre-commit-config.yml file. Thanks
again
On Thu, 20 Apr 2023 at 17:11, Zachary Rice @.***> wrote:

This is a pre-commit specific error. I don't have a solution but maybe
someone in the community does. Thanks for trying to reproduce, @rgmz
https://github.com/rgmz
—
Reply to this email directly, view it on GitHub
https://github.com/gitleaks/gitleaks/issues/1157#issuecomment-1516600548,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACIB3UOH2GHA26T45JABVZDXCFN35ANCNFSM6AAAAAAXFV6CBM
.
You are receiving this because you authored the thread.Message ID:
@.***>


Manually installing pre-release VSIX does not register it as prerelease

With VS Code Insiders, when I install a prerelease of our new platform-specific VSIX, it does not register as prerelease:

This issue only occurs with VS Code Insiders:
Version: 1.64.0-insider (user setup)
Commit: 23aa7ad51c95d90d48b1d352a316d7f0c2c4310d
Date: 2022-01-18T09:44:38.476Z
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 10.0.22000
This does not repro with VS Code (non-Insiders, 1.63.2).  That displays the prerelease indication correctly, when installing the very same VSIX:

Can you please share the VSIX to try out and reproduce?

I think I am seeing this too, with an extension for which regular and pre-release versions have been published on Marketplace

Package a pre-release VSIX: vsce package --pre-release
Install the VSIX by dropping it into the Extensions view.
Reload if prompted.
:bug: The entry in Extensions view doesn't display as a pre-release.

I am 100% sure the VSIX got built with the --pre-release switch. Indeed, when I subsequently upload it manually onto Marketplace it correctly lists as a pre-release, and installs as a pre-release.

Hi @sandy081 .  The issue repro's with v1.8.0 (prerelease) of the C/C++ extension in the marketplace.  (The same as pictured).  You can download it directly from the marketplace web site here: https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools  When installed from within VS Code, the same VSIX shows as Prerelease.

@Colengms Thanks for filing the issue. I can repro it and fixed it.
@gjsjohnmurray VS Code can detect if the installed VSIX is a pre-release or not only if the VSIX is published to the Marketplace. Because VS Code gets pre-release information from Marketplace and not from the VSIX.

VS Code can detect if the installed VSIX is a pre-release or not only if the VSIX is published to the Marketplace.

@sandy081 I think VS Code should get this information from the VSIX manifest. Here's an example of how it can be done:
https://github.com/microsoft/vscode-vsce/blob/9b2b16b9d7cab894b98d9680f9becf63910816dc/src/publish.ts#L57-L59

That's true - but this could cause inconsistency if the author publishes the package with same version without pre-release flag. Hence, I prefer Marketplace to be the source of truth. Anyway this will be temporary until Marketplace supports the SemVer completely and then we can get the information from the version.

@sandy081 this isn't making sense to me.

In my extension's package.json I set version to, say, "1.3.2022012301" and package it with the command vsce package --pre-release to create a VSIX file.
Without uploading this to Marketplace, and with no matching version already existing on Marketplace, I install it locally (e.g. drag/drop onto the Extensions view).
It gets installed but not treated as a pre-release.

Why? Are you asking Marketplace "Is 1.3.2022012301 a pre-release version?" and treating any response other than "Yes" as meaning "No"? Even an answer that means "I know nothing about version 1.3.2022012301"?

Yes, I ask Marketplace if a version is a pre-release or not. It works like this:

when you package the vsix using vsce with pre-release flag, it adds this metadata to the vsix.
marketplace stores this metadata when this vsix is published
vscode gets the metadata from the marketplace and determines if it is a pre-release or not.

This pre-release flag to the vsce is partial support until marketplace supports semver completely, going forward, the pre-release type is checked from the version. For eg., if the version is 1.2.3-insiders then the version is considered as a pre-release. Therefore if you install the extension from vsix or from marketplace, vscode detects the pre-release from the version. We knew that the current solution is not the ideal but it helps and avoid many extensions which are creating duplicates for pre-releases/insiders. Once marketplace supports semver, extensions can start adopting to the semver versioning for pre-releases.
As you said, the metadata is still part of the vsix. At present, vscode is not reading this metadata as we rely on marketplace for this metadata. I would not do this for following reasons:

Source of truth is Marketplace.
We can always override it after reading from Marketplace, but I think its not worth to read and parse an additional manifest file (xml) just for this use case. Anyway the installed vsix will be shown as pre-release as soon as you publish the vsix to marketplace.

Hence my recommendation for this feature is to wait for MP support for SemVer. Hope you agree with this.

We can always override it after reading from Marketplace

I don't want the vsix's embedded manifest to override what Marketplace says about the extension being or not being a pre-release. But when Marketplace can't answer that question (because this particular version of the vsix hasn't been published) I feel strongly that VS Code should consult the embedded manifest.
A specific use-case is that we are not permitted to publish to Marketplace a vsix that we build with proposed APIs enabled. We often want to build these so our adventurous users can download and install them (e.g. as artefacts of a GH workflow).
It is confusing when a user has installed a pre-release from Marketplace, and then they manually install a pre-release vsix built with proposed APIs enabled, and suddenly their Extensions view tells them they're running a release vsix for which a pre-release is available. If they click the button to install the pre-release, they end up downgrading to one that doesn't use proposed APIs.
Do you have an estimate for when MP will support SemVer?

Ah I see your use case. You can do following:

You can tag your VSIX version with pre-release tag, for eg: 1.1.1-pre-release
VS Code will detect from the vsix version if it is pre-release or not (This is yet to support)

You are forced not to publish this VSIX because the Marketplace does not support this versioning yet. If you want to publish you can increase the minor version (for eg) without pre-release tag and publish it as pre-release to Marketplace. VS Code will automatically update to latest pre-release.
Since this is not yet supported, can you please create a separate issue for this use case?

Do you have an estimate for when MP will support SemVer?

Estimating by the end of this year.

Verified that the pre-release badge for v1.8.0 of the C++ extension shows up when installing the VSIX by dragging it into the extensions panel

One interesting thing I noticed: If installing a prerelease VSIX that is not yet published to the marketplace (for testing, prior to publishing), the extension is not identified as prerelease.  I suspect that's because the marketplace is the authority on whether that version number is a prerelease, not the field in the VSIX manifest.

@Colengms that is what I am unhappy about. I think in this situation VS Code should extract the vsix manifest file and check for the attribute value which marks it definitively as a pre-release. It won't be hard to do, and I am even considering submitting a PR if @sandy081 is willing to consider it after the current endgame is past.

@gjsjohnmurray Agreed that it is not hard, but I think this will be redundant when we move to SemVer. It seems to me not a prominent use case for implementing and removing it later. This can be waited until Marketplace supports SemVer. Just to be clear, this needs parsing the XML manifest file and VSCE uses xmltojs library, which means we have to add this dependency to VS Code or parse the xml file ourselves. I do not see a reason to do this if we do not need this in future.

Created a separate issue - https://github.com/microsoft/vscode/issues/141869 to track this. Lets continue conversation there.
Thanks.


GH-1531: fixed NPE in MicrometerHolder during app shutdown

fixed NPE issue in MicrometerHolder during app shutdown (https://github.com/spring-projects/spring-kafka/issues/1531)

@vasiliy-sarzhynskyi Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.

@vasiliy-sarzhynskyi Thank you for signing the Contributor License Agreement!

Thanks!


fix(snapshot): proper error propagation from remote replicas

Errno codes are now peoperly propagated to nexus node from replica nodes when creating snapshots on remote replicas.

bors try

bors try

bors cancel

bors try

bors merge

bors merge


Optimize API calls

Is your feature request related to a problem? Please describe.
Web client fetches brings data together from different API's, and that often. For example, on entity history page history entries and the users for each entry a fetched. Under certain circumstances it can lead to the same user being loaded several times (e.g. one user produce many entity updates). That is not dramatic, but inefficient, we can do it better!
Describe the solution you'd like
While fetching a list of entities required by another entity, each entity should be fetched only once. We need to add extra sugar to our existing api.js module.
Additional context
Applies mostly to History and Reviews page (currently)

@setaman is HTTP caching currently working? Could also save us some full requests.

@DaTebe
on the backend side, we have no explizit mechanisms for API response caching. Browser seem not to cache API request


griddle 1.0: DefaultModules is not available

1.0 documentation states:

The DefaultModules can be included and used as follows:
import Griddle, {DefaultModules} from 'griddle-react';

But DefaultModules is not exported

Thanks for calling this out. This should now be fixed. Please feel free to follow up if you encounter any problems.


Allow mixin constructor have parameters before rest parameter

Search Terms
mixin, constructor parameters
Suggestion
Allow mixin constructor have parameters before rest parameter and infer the combination between mixin parameters.
Use Cases
The following js code is completely valid and functional. However with the actual mixin constructor constraints we can't reproduce this in Typescript.
const mixin1 = (base) => class Mixin1 extends base {
    constructor(m1v1, m1v2, ...args) {
        super(...args);
        this.m1v1 = m1v1;
        this.m1v2 = m1v2;
    }
};
const mixin2 = (base) => class Mixin2 extends base {
    constructor(m2v1, m2v2, ...args) {
        super(...args);
        this.m2v1 = m2v1;
        this.m2v2 = m2v2;
    }
};
class Base {
    constructor(v1, v2) {
        this.v1 = v1;
        this.v2 = v2;
    }
}
class C1 extends mixin1(Base) {
}
class C2 extends mixin2(Base) {
}
class C3 extends mixin2(mixin1(Base)) {
}
console.log(new C1("m1v1", true, 1, {}));
console.log(new C2(false, 2, 1, {}));
console.log(new C3(false, 2, "m1v1", true, 1, {}));

Examples
Same code expected work in ts with constructor inference.
type Constructor = new (...args: any[]) => object;

const mixin1 = <T extends Constructor>(base: T) =>
    class Mixin1 extends base {
        m1v1: string;
        m1v2: boolean;

        constructor(m1v1: string, m1v2: boolean, ...args: any[]) {
            super(...args);

            this.m1v1 = m1v1;
            this.m1v2 = m1v2;
        }
    }

const mixin2 = <T extends Constructor>(base: T) =>
    class Mixin2 extends base {
        m2v1: boolean;
        m2v2: number;

        constructor(m2v1: boolean, m2v2: number, ...args: any[]) {
            super(...args);

            this.m2v1 = m2v1;
            this.m2v2 = m2v2;
        }
    }

class Base {
    v1: number;
    v2: object;

    constructor(v1: number, v2: object) {
        this.v1 = v1;
        this.v2 = v2;
    }
}

class C1 extends mixin1(Base) {
}

class C2 extends mixin2(Base) {
}

class C3 extends mixin2(mixin1(Base)) {
}

console.log(new C1("m1v1", true, 1, { })); // infer mixin1 and Base parameters: [string, boolean, number, object]
console.log(new C2(false, 2, 1, { })); // infer mixin2 and Base parameters: [boolean, number, number, object]
console.log(new C3(false, 2, "m1v1", true, 1, { })); // infer mixin2, mixin1 and Base parameters: [boolean, number, string, boolean, number, object]

Checklist
My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

Hey! As you explicitly call super in mixin, then normal rules for matching function args should apply.
This way if you are using "options" like creation, you might have something like in linked Playground?
(Playground Code)[https://www.typescriptlang.org/play/index.html?ssl=71&ssc=13&pln=71&pc=14#code/C4TwDgpgBAwg9gOwM7AE4FcDGw6qgXigQgHcoAKAOmoENUBzJALihoRAG0BdASgID4ocAEYArCNgDcAKGkBLBMAioAZjUzQAkgDkaAWwgATACI1gNKAG9pUW1FQQahxABsQRfRBYpUC+jIBfaUxEFChdA0MCKAAeABUoCAAPJQRDJFhQtCwcVH5yYRokLyg4vnx+GztMFyKM5NT0qELiqyq7OwcnV3cET280Pxl2jqgQ5GzsXHJDMxoWHU8TOb5rUfWoJHRIVBmVmQ3R4AALOSRKPoNo2fMLzwONoI6g+UVlNQ0oTTiaenojUzmNodLrOBBuKDmRgsABKjjBbgAgqhUDQQDEfH5+IFgllSr9-lFCPFEikIGkMvAJhgpnkCkUSmUBCManVSY0Mi1oGsNqCepDfswoHDuuCQABlCDADGDBD0bGyQ7jHw5aY3eZfH5-AErYGHOxbHZ7cw8B76o6nc5QjKEYhkSXAY00SjW00jZ4jF4KJSqdRabToPTCZQAGTkAGsIICLJYoAA3GgudAlBCB4OoSRQIKspAZANB0MR7kjPli+OJ5MsVMFjOK6pZGm5J0LfPpsOR6OrSGWygJpPQQjq3sViCZoJet6+z7fBrtqNzKzl-sDXxysfBWq50qzot62yliF9yubWX+Ou2ZWTJvqhZxHcd3U89YnM7D-vXOZv5NmrPSF45ykAEZ2XJJoIiMchW0LSNVhZBtVV2G8vig1A52jKAADJkKWTs91GQ1lCdN0PX-TdKQAJhAil8W1QxIKWcg7xSOceFgjpL0bNU5lve95yBLDFkidCBK1QlcKffDtkI9ViLscdZFxCYxmA21SFgQDyAko8SgAdgAGigAB6QyoBUXBwjTaCIBGS4SgAIkwQC7KMkyzLwcDDBsAI3UvMZKNUsgYHIzSRm0lg7KSAANJI7IM4zTPMlC5xs-ooAc8jYpchL3KWEZrRYDgIsyuyQGKgAvOyuCytyaMJP83UUsIYDIgBmaJRIgjzIMs1Ci1YmRfMwNqAtgVqQo6MKoAAFji1zzKY4Bko6WzwqGzL4pqjy8sFAq7IAEmKgBiYqAAFKuq+aCSMerZGVOAXAgSgXDgehyAAA0coy9ssRyvwgAJDO+37bIBt6fNCe7Hue16PsowGfvIv6AaBxGQfhzBEetP6kHIHgLgaXGkcMsGBohh6npe96hq+n6WqJoG6bRhmXUFbHCeIFJCe00G3SAA]

If I understood. For this type of composition to be possible, the mixin should also know the parameters of the base class. Whether it could be implemented through a generic constraint.
const INeedTagsMixin = <T extends new (options: INeedNameAndTagsOptions) => any>(base: T) =>
  class INeedTagsMixin extends base {
    tags: Map<string, string>;
    constructor(options: INeedNameAndTagsOptions) {
      super(options);
      this.tags = new Map(options.tags);
    }
}

It would be an interesting addition.

Not exactly. I would like to have option to specify more restricted constructor that "...args: any[]". The mixin from your example would have 2 generic arguments. The mixing class constructor would be intersection of required options' properties plus generic TOptions.
interface INeedTagsOptions {
  tags: ReadonlyArray<[string, string]>;
}
// I need to define that this mixin requires TOptions ctor arg to match below super call
const INeedTagsMixin = <T extends new (options: TOptions) => any, TOptions>(base: T) =>
  class INeedTagsMixin extends base {
    tags: Map<string, string>;
    // here we need INeedTagsOptions to init self and whatever type of constructor arg when used
    constructor(options: INeedTagsOptions & TOptions) {
      super(options); // here we only need TOptions to satisfy "base" ctor
      this.tags = new Map(options.tags);
    }
  }

class Class1 {
  readonly x: number;
  constructor(options: { x: number }) {
    this.x = options.x;
  }
}
class Class2 {
  readonly name: string;
  readonly ugly: boolean;
  constructor(options: { name: string, ugliness: number }) {
    this.name = options.name;
    this.ugly = options.ugliness > 4;
  }
}

const T1 = INeedTagsMixin(Class1);
const t1 = new T1({ x: "xx", tags: [["a", "aa"]] });
console.log(t1.tags.get("a"));
console.log(t1.x);

const T2 = INeedTagsMixin(Class2);
const t2 = new T2({ name: "zz", ugliness: 6, tags: [["a", "aa"]] });
console.log(t2.tags.get("a"));
console.log(t2.ugly);


lock_video_orientation does not work in Android 14

Will the fix be abandoned?

Need to be implemented in a different way. See https://github.com/Genymobile/scrcpy/pull/4658#issuecomment-1936558849
Closing as duplicate of #4011.


www.ioscreator.com down

let's remove or close this issue on Jun 1
https://www.ioscreator.com/

Any idea how long is it down? Was iterating through some redirects today and stumbled on errors caused by iOSCreator on Travis. 🤔

not sure.. new problem I think ?

Probably. Last commit on @ioscreator's repository was 14 days ago.
Let's wait and remove (or hopefully, just close this one).
🙌

I'm closing this issue because iOScreator is back.
Feel free to reopen if you want to.


Unwind info for Windows may not be correct for entire function prologue

With a debugging session last Friday about Windows-specific CI failures we ended up concluding that CI failures were tied to Github Actions' recent upgrade of the windows-latest image from windows-2019 to windows-2022. The PR to temporarily pin to windows-2019 has landed and CI is fixed for now but we also did some further investigation to figure out what about windows-2022 was causing breakage.
With the investigation on https://github.com/bytecodealliance/wasmtime/pull/3853 the conclusion was that one of the failing tests was wast::Cranelift::misc::stack_overflow. Some further investigation showed that all stack overflow tests were failing. Digging further into this our first conclusion was https://github.com/bytecodealliance/wasmtime/issues/3857 which is separate from this issue, but we realized that reproducing this issue required running tests on separate threads, at least with --test-threads 2.
The previous CI failures we were seeing were out-of-memory errors on the tune of 5GiB allocations. It turns out that Backtrace::new_unresolved was the culprit as the stack trace was hitting an "infinite loop" where the stack wasn't actually infinite but the stack unwinder was infinitely looping over frames. We attempted to collect (https://github.com/bytecodealliance/wasmtime/issues/3858) all these frames which resulted in OOM.
That's all basically a long-winded way of saying that the system-generated stack trace on windows-2019 was correct while the stack trace on windows-2022 was an "infinite" stack trace (despite it not actually being infinite). For a simple WebAssembly module:
(module
  (func call 0)
)

the cranelift machine IR emitted for this is:
VCode_ShowWithRRU {{
  Entry block: 0
Block 0:
  (original IR block: block0)
  (successor: Block 1)
  (instruction range: 0 .. 13)
  Inst 0:   pushq   %rbp
  Inst 1:   unwind PushFrameRegs { offset_upward_to_caller_sp: 16 }
  Inst 2:   movq    %rsp, %rbp
  Inst 3:   movq    0(%rdi), %r10
  Inst 4:   movq    0(%r10), %r10
  Inst 5:   cmpq    %rsp, %r10
  Inst 6:   jbe ; ud2 stk_ovf ;
  Inst 7:   unwind DefineNewFrame { offset_upward_to_caller_sp: 16, offset_downward_to_clobbers: 0 }
  Inst 8:   movq    %rdi, %rax
  Inst 9:   movq    %rax, %rdi
  Inst 10:   movq    %rax, %rsi
  Inst 11:   call    User { namespace: 0, index: 0 }
  Inst 12:   jmp     label1
Block 1:
  (original IR block: block1)
  (instruction range: 13 .. 16)
  Inst 13:   movq    %rbp, %rsp
  Inst 14:   popq    %rbp
  Inst 15:   ret
}}

When wasm hits the fault at "Inst 6" above due to stack overflow this is before the DefineNewFrameunwind pseudo-instruction, but that instruction should probably be just after "Inst 2" instead of at the end of the prologue that checks the out-of-stack condition. The current suspicion is that this probably-incorrect location ofDefineNewFrameis why thewindows-2022` stack unwinding hits an infinite loop.
It's worth noting that one of the debugging runs on https://github.com/bytecodealliance/wasmtime/pull/3853 printed out the ip/sp of each frame on the stack and it looked like:
0: ip=0x7ff62df77637 sp=0x7c55af8d20
1: ip=0x7ff62df77637 sp=0x7c55af8d20
2: ip=0x7ff62df77527 sp=0x7c55afabd0
3: ip=0x7ff62df54c33 sp=0x7c55afac40
4: ip=0x7ff62df55303 sp=0x7c55afae30
5: ip=0x7ff62df635a7 sp=0x7c55afaea0
6: ip=0x7ff62df55238 sp=0x7c55afaf10
7: ip=0x7fff1896b592 sp=0x7c55afaf60
8: ip=0x7fff18922022 sp=0x7c55afb000
9: ip=0x7fff18992e1e sp=0x7c55afb240
10: ip=0x1d76a8f1013 sp=0x7c55afc010
11: ip=0x7c55afc020 sp=0x7c55afc018
12: ip=0x1d76a8f1023 sp=0x7c55afc020
13: ip=0x7c55afc030 sp=0x7c55afc028
14: ip=0x1d76a8f1023 sp=0x7c55afc030
15: ip=0x7c55afc040 sp=0x7c55afc038
16: ip=0x1d76a8f1023 sp=0x7c55afc040
...
22446: ip=0x1d76a8f1023 sp=0x7c55b27d30
22447: ip=0x7c55b27d40 sp=0x7c55b27d38
22448: ip=0x1d76a8f1023 sp=0x7c55b27d40
22449: ip=0x7c55b27d50 sp=0x7c55b27d48
22450: ip=0x1d76a8f1023 sp=0x7c55b27d50
22451: ip=0x7c55b27d60 sp=0x7c55b27d58
22452: ip=0x1d76a8f1023 sp=0x7c55b27d60
22453: ip=0x7c55b27d70 sp=0x7c55b27d68
22454: ip=0x1d76a8f1023 sp=0x7c55b27d70
22455: ip=0x7c55b27d80 sp=0x7c55b27d78
22456: ip=0x1d76a8f1023 sp=0x7c55b27d80
22457: ip=0x7c55b27d90 sp=0x7c55b27d88
22458: ip=0x1d76a8f1023 sp=0x7c55b27d90
22459: ip=0x7c55b27da0 sp=0x7c55b27d98

where the ip is seemingly correct in that this was a mutally recursive set of functions as part of the test case and the sp is indeed increasing, but there seems to be no limit to sp increasing and apparently no reads/writes of memory are being done because presumably it would have otherwise segfaulted at this point!
In any case it appears that bad unwinding information is to blame here on Windows, so this issue is intended to track fixing that, and a fix for this issue should likely be accompanied with a revert of https://github.com/bytecodealliance/wasmtime/pull/3854 as well.

cc @cfallin, @peterhuene

Some notes here: I've been paging in details on the unwind generation and ABI code and this will require a bit of surgery to fix I think. In particular:

The DefineNewFrame unwind pseudo-inst (defined here) has info about clobber-frame size.
This means that the generation of this pseudo-inst here (for x64, but similarly for others) needs to occur in the clobber-saving trait method, which is invoked after the initial prologue (push rbp / mov rbp, rsp).
The info about clobbers is currently needed because in the translation both to winx64 unwind and systemv unwind we save info to be able to generate the correct offsets with subsequent clobber saves.

I think the simplest approach is probably to split the function of DefineNewFrame into two parts: the actual setting of the FP register, and the metadata used to generate FP- or SP-relative offsets for clobber saves. I'll see what I can do about that.

Hmm, and as an added twist, when generating the SetFPReg Windows unwind record we need to know the size of the clobbers, so we actually can't do the split I suggested above; we need to process clobbers (at least know their size) before we generate the unwind info for setting the FP, which itself happens before the stack check (and must be so, as Windows requires a fairly rigid prologue sequence). So the way in which we handle stack check generation has to change overall. Will consider more!


Fix Gemfile.lock install error

Coverage decreased (-0.6%) to 96.954% when pulling 72a79ef8e242a5c9582474d9bc659d4eb3188417 on oniofchaos:fix-gemfile-lock into 673298382c502bfe9683f685200e0a0704855c60 on devise-security:master.


Stateful partitioners

Pre-review checklist
Currently, partitioners require the whole input to be passed in a single contiguous slice, which often forces an allocation that could else be avoided.
Hence, this PR refactors partitioners' API so it resembles std::hash API:

Partitioner corresponds to BuildHasher as it becomes kind of a factory,
PartitionerHasher is introduced and corresponds to Hasher. It contains the hashing state, which enables feeding it with multiple chunks of data separately.

The test is added that ensures consistent hashing result no matter how the partition key is partitioned into chunks.
After the partitioners gain ability to partition by chunks, the codebase is modified so that all needless allocations of partition key are avoided.
As there was one more place where materialised partition key was used - by putting it into the produced trace - a PartitionKeyDisplay struct is introduced that computes the key upon call to display(), avoiding materialisation and saving an allocation there too.

[x] I have split my patch into logically separate commits.
[x] All commit messages clearly explain what they change and why.
[x] I added relevant tests for new features and bug fixes.
[x] All commits compile, pass static checks and pass test.
[x] PR description sums up the changes and reasons why they should be introduced.
[x] I have provided docstrings for the public items that I want to introduce.
[ ] I have adjusted the documentation in ./docs/source/.
[ ] I added appropriate Fixes: annotations to PR description.

Any measurable performance impact?

Any measurable performance impact?

Number of allocations has dropped (6 -> 5 per insert, 19 -> 18 per select).
Before:
Args { mode: All, node: "<IP_ADDRESS>:9042", parallelism: 256, requests: 100000 }
Connecting to <IP_ADDRESS>:9042 ...
Sending 100000 inserts, hold tight ..........
----------
Inserts:
----------
allocs/req:                 6.08
reallocs/req:               6.00
frees/req:                  6.07
bytes allocated/req:      272.75
bytes reallocated/req:     73.06
bytes freed/req:          267.77
----------
Sending 100000 selects, hold tight ..........
----------
Selects:
----------
allocs/req:                19.00
reallocs/req:               6.00
frees/req:                 19.00
bytes allocated/req:     1123.09
bytes reallocated/req:     73.00
bytes freed/req:         1123.03
----------

After:
Args { mode: All, node: "<IP_ADDRESS>:9042", parallelism: 256, requests: 100000 }
Connecting to <IP_ADDRESS>:9042 ...
Sending 100000 inserts, hold tight ..........
----------
Inserts:
----------
allocs/req:                 5.08
reallocs/req:               5.00
frees/req:                  5.07
bytes allocated/req:      265.09
bytes reallocated/req:     77.06
bytes freed/req:          260.06
----------
Sending 100000 selects, hold tight ..........
----------
Selects:
----------
allocs/req:                18.00
reallocs/req:               5.00
frees/req:                 18.00
bytes allocated/req:     1115.19
bytes reallocated/req:     77.00
bytes freed/req:         1115.05
----------

Any measurable performance impact?

Number of allocations has dropped (6 -> 5 per insert, 19 -> 18 per select).

Please prepare a microbenchmark for this. While an allocation is now avoided, the new implementation has more branches, so it will be interesting to see whether the tradeoff was worth it.
We are basically interested in the PreparedStatement::compute_partition_key function. Interesting cases are single-column pks with different lengths and multi-column pks with different lengths.
We already have a small amount of benchmarks in scylla and scylla-cql, you can look at them for reference (and at the external criterion crate that those benchmarks use).

Please prepare a microbenchmark for this. While an allocation is now avoided, the new implementation has more branches, so it will be interesting to see whether the tradeoff was worth it.

After benchmarks and some changes to the algorithm, the new way seems to outperform the old way by 15% to 40% in various cases. I believe this suffices to merge this.

NICE! Well done! Would be happy to see details of this tests.

CI fails due to use of Option::unzip(), which is stable since Rust 1.66, whereas our MSRV is 1.65. Can we bump it @piodul?
Apart from that, ready for review.

I reimplemented Option::unzip() (technically, copied its code from the standard library) temporarily, not to force MSRV bump yet.

Rebased on main.


new technique to search for plugins

issue: Optimize plugins discovery #1733
brief about the proposed technique :
1- store all plugins information ( entry_point, name,register_function)
2- search once in all paths and in each path search if  one of the plugins exists  , if so , then load it to the cache and call  the plugin's register_factory_function.

Something is off with your PR, it includes 4078 changed files! You'll need to clean things up and open a new one.


Fix publishing packages

Hi @jiri-otoupal, I noticed the CI is failing for publishing packages on main. I would like the use the latest changes. Would it be possible to get a release soon?
Thanks,

Hansel

Hi, its fixed now.
Thanks,
Jiri


Migrate code from original bridge branch

The point of this PR is to simply move the WIP predicate/script code from the original bridge repo to this new one. You'll notice a lot of TODOs in the code and there's a lot of work to do, but this should help with tracking code changes. Some modifications were made to get a simple test working. This test treats the InputMessage as an InputCoin for now and will be updated once the SDK adds support for InputMessages.

I'm getting a little confused with the use of - vs _ for project names and things listed in the files. I suggest picking one or the other and sticking to it

So the dashes were changed to underscores for the actual project name specifically for the case of contract_message_receiver because the dashes caused a compilation error when other scripts try to 'import' it use contract_message_receiver::L2ERC20Gateway;. I'm not sure if this issue has been run into before or how it should be addressed. I know rust prefers module names to be in snake_case

I had a to-do from last week to enumerate test cases for this setup. Basically apart from the succesful spend (which you have already tested here), we just need to hit each of the assert cases once and check that the transaction is invalid as expected.


Pass though "dir" attribute

The component currently does not allow setting "dir" attribute, which would be useful for many rtl/ltr/bidi cases, especially since you can only set "auto" direction via this attribute.

I will see if I can find time to implement this, otherwise PRs are very welcome!

sorry about the late reply. This should be now fixed in version 3.0.0 where you can pass any attribute. Upgrades require to migrate due to two way binding no longer being available with current ember versions.


Pass permissions along for SourceFile symlinks

Dir, file, and symlink permissions are passed on (and ignored until #4) but symlinks for files are not handled.

Removed Access for now, so is part of #4


jsx in zustand store function throws error with vitest and testing-library

Describe the bug
I use react-hot-toast to dispactch a toast after setting the state in a store function of a zustand strore:
export const useJobStore = create<JobStore>()(
  persist(
    (set, get) => ({
      lastDoneJob: undefined,
      completeJob: (jobKey: JobMapKeys) => {
          // ... logic

          set((state) => ({
            // ...state
          }));

          toast(<ToastJobMessage/>, {
            icon: <SomeIcon />,
            duration: 3000,
          });
      },
    }),
    {
      name: 'levelStore',
    }
  )
);

this works all well on the page but when i want to run my testsuite with vitest and testing-library
I get the following error:

for reproduction please run the test script in the codesandbox
Reproduction
https://codesandbox.io/p/sandbox/tender-villani-qzjxge
System Info
System:
    OS: Windows 10 10.0.19044
    CPU: (12) x64 AMD Ryzen 5 5600G with Radeon Graphics

    Memory: 18.03 GB / 31.41 GB
  Binaries:
    Node: 18.12.1 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.15 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 8.8.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Spartan (44.19041.1266.0), Chromium (110.0.1587.63)
    Internet Explorer: 11.0.19041.1566
  npmPackages:
    vitest: ^0.29.1 => 0.29.1

Used Package Manager
pnpm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

thanks


Update crefs

Right now I see the following in VS built-in decompiler:
Date formatted strings, e.g. "\/Date(1198908717056)\/" and "2012-03-21T05:40Z", are parsed to Newtonsoft.Json.DateParseHandling.DateTime.

Woohoo, thanks 🎉


Prevent updating HelmRepository

Same reason as for https://github.com/giantswarm/renovate-presets/pull/21

Waiting for @mproffitt or @ljakimczuk to confirm that this is correct.


Keyboard manager can't handle/not working with brightness up / down function keys

Microsoft PowerToys version
0.69.0
Installation method
WinGet
Running as admin
No
Area(s) with issue?
Keyboard Manager
Steps to reproduce

Go to keyboard manager -> Remap keys (重新映射键)
Add a new remap, and click "input" (输入) button.
Press the brightness up / down keys and feel the bug.
PowerToysReport_2023-04-10-23-15-26.zip

✔ Expected Behavior
These keys got recognized by powertoys and able to remap them.
❌ Actual Behavior
These key will not get recognized by powertoys but they does adjusted the monitor brightness.

Other Software
No response

Note: The keyboard used is the one that comes with my Pavillion Desktop (model HSA-P003K) which have funtion keys enabled by default and NO WAY TO DISABLE. Forced use software remapping instead.
https://h30434.www3.hp.com/t5/Desktop-Hardware-and-Upgrade-Questions/FN-key-lock-on-new-Pavillion-Desktop-No-BIOS-option/td-p/6982295

/dup https://github.com/microsoft/PowerToys/issues/20405


Invisible carts?

Minecraft 1.14.4
Mod version: AstikorCarts v<IP_ADDRESS>
I'm trying to put down a cart in creative mode and it seems to be invisible.
Placing down a cart just next to a horse pushes the horse a little, but nothing else. There's no collision afterwards nor anything to be seen where it was placed. Changing the mode to survival just consumes the cart and still there's nothing there.

"I should also mention that you will need at least Forge v1.14.4-28.1.41 to run this mod". Ok, get it, I'll close this after i try it

lmao, it works


Issue when currentlyFocusedInput is not found

I'm experiencing an issue on this line:
https://github.com/rlemasquerier/react-native-keyboard-scrollview/blob/62eced0540e30d32a546225d0dcae84304a2eb5f/src/KeyboardScrollView.tsx#L64
I'm getting this error: TypeError: Cannot read property 'measureInWindow' of null. That means this line
const currentlyFocusedInput = TextInput.State.currentlyFocusedInput();

is returning null
Now in my use case, this error happens when I switch between clicking on TextInputs that are sometimes disabled (since I want the look of a text input, but use an onPress to interact with instead). I'm wondering if your code would not be able to read it if it's disabled, and if that is why it's returning that type error? Otherwise I guess just finding a solution where you confirm that currentlyFocusedInput exists, eg currentlyFocusedInput?.measureInWindow

Hello @jacquesdev and thank you for reporting this issue!
I have tried to add a disabled text input in the example app (I have committed this change so you can test yourself 🙂) but I did not reproduce the error. Perhaps you are using an older version of react native ?
Anyway, I have published a new version by adding your suggested fix with a safety operator, as it does not cost anything. Does it solve your issue?


How can I get the clone of original request?

Hi there,
Thank you to everyone in this community, you have inspired me a lot.
I'm working on proxy feature with Hono, is there possible to get original request object ? then I don't have to parsebody and set the header manually ,
just like: https://developers.cloudflare.com/workers/examples/bulk-origin-proxy/
`const ORIGINS = {
'starwarsapi.yourdomain.com': 'swapi.dev',
'google.yourdomain.com': 'www.google.com',
};
function handleRequest(request) {
const url = new URL(request.url);
// Check if incoming hostname is a key in the ORIGINS object
if (url.hostname in ORIGINS) {
const target = ORIGINS[url.hostname];
url.hostname = target;
// If it is, proxy request to that third party origin
return fetch(url.toString(), request);
}
// Otherwise, process request as normal
return fetch(request);
}
addEventListener('fetch', event => {
event.respondWith(handleRequest(event.request));
});`

Hi @xoosye !
We can get the original request by using c.req like this:
app.all('*', (c) => {
  const url = new URL(c.req.url)
  if (url.hostname in ORIGINS) {
    const target = ORIGINS[url.hostname]
    url.hostname = target
    return fetch(url.toString(), c.req)
  }
  return fetch(c.req)
})

Try it and let me know if you still have problems.

Hi @xoosye !
We can get the original request by using c.req like this:
app.all('*', (c) => {
  const url = new URL(c.req.url)
  if (url.hostname in ORIGINS) {
    const target = ORIGINS[url.hostname]
    url.hostname = target
    return fetch(url.toString(), c.req)
  }
  return fetch(c.req)
})

Try it and let me know if you still have problems.

That works!
Thank you @yusukebe !
Hono is awesome!


Version 4

This PR removes all features we have marked as deprecated in v4 pre.
The following features have been removed:

The local-time element has been removed.
The time-ago element has been removed.
The time-until element has been removed.
getFormattedTitle is now only private.
getFormattedDate is now only private.
format no longer accepts a strftime compatible format. Instead, any value other than 'micro', 'elapsed' will revert to the string 'auto'
the Intl.DateTimeFormat constructor is not ponyfilled, and so in environments without this constructor, the
element will fall back to provided text.
the Intl.RelativeTimeFormat constructor will not be ponyfilled, and so in environments without this constructor, the element will fall back to provided text.

:wave: Hello and thanks for pinging us! This issue or PR has been added to our inbox and a Design Infrastructure first responder will review it soon.

:art: If this is a PR that includes a visual change, please make sure to add screenshots in the description or deploy this code to a lab machine with instructions for how to test.
:fast_forward: If this is a PR that includes changes to an interaction, please include a video recording in the description.
:warning: If this is urgent, please visit us in #primer on Slack and tag the first responders listed in the channel topic.


cannot import name 'cached_property'

  File "/usr/local/lib/python3.6/site-packages/openapi_tester/loaders.py", line 5, in <module>
    from functools import cached_property
ImportError: cannot import name 'cached_property'

I get this error when using drf-openapi-tester 1.3.2. After a quick investigation, it seems that functools.cached_property was introduced in python 3.8 and I'm using 3.6.
There's another cached_property decorator in django.utils.functional. Since django is already a dependency of this project, can we switch to using that one instead?
Thanks!

Thank you for the report @idesoto-rover. This sounds very reasonable; we will support Python 3.6 for the foreseeable future, so adding a 3.8 feature was definitely an oversight on our part.
I'll see if I can resolve this some time today and publish a new version.

Just published v1.3.3 @idesoto-rover 🙂  Hopefully this will resolve this issue. To be sure, I (eventually managed to) set up Python 3.6 locally to do some testing and it looks good for me at least. Let me know if you spot anything else 👏

That was quick! It works like a charm. Thank you so much!


CATs docker tests are failing

Describe the bug
When enabling the include_docker tests for CATs, all docker tests fail.
To Reproduce
See https://concourse.suse.dev/teams/main/pipelines/kubecf/jobs/cf-acceptance-tests-diego/builds/164#L5e84c8c5:11425:11527
Expected behavior
Tests should be passing.
Additional context
None

So, I get success when I enable the feature with cf enable-feature-flag diego_docker.
Ran 3 of 213 Specs in 79.165 seconds
SUCCESS! -- 3 Passed | 0 Failed | 0 Flaked | 1 Pending | 209 Skipped

Ginkgo ran 1 suite in 1m19.391493533s
Test Suite Passed

@viovanov Do we want this feature enabled by default?

@f0rmiga yes, let's enable it by default
FYI @troytop

I'll make it enabled by default as part of this issue, then.

Do not change the diego_docker default setting in KubeCF. We should keep it disabled by default as long as cf-deployment does. Please instead change the test to run a cf enable-feature-flag diego_docker before executing the relevant tests.


enable overriding package config per job

Fixes https://github.com/packit-service/packit-service/issues/418
p-s PR

Conditional ACK if you update https://packit.dev/docs/configuration as well.

'duh

still want to hear at least one more opinion on this since the implementation is controversial to me

* Looks good from the developer perspective. (But not so clean TBH.)

Yes, first I started implementing it by reusing all the package config parsing and schema but realized it would be +1000-1000 and would be insanely complicated and fragile for a small benefit - the same validation we have in the rest of the package config. If the present implementation proves to be inefficient, we can always improve.

* I am not sure if users want to have `overrides` key there. They will probably want to specify those values directly. But it's better to have worse UX than nothing...;)

It's our config :D it matter what we want to have there, I'd say people in the end don't give a damn unless it works well.
My thinking with the overrides is:

One can clearly see every override in a job, they don't get boggled with the rest of the params.
We also have dedicated metadata key, so we're consistent.
It makes it much more easier to implement on our side.

TBH, overrides is a pretty bad user experience. Reading a job definition with overrides is going to be a more brain intensive task than necessary. Just to be clear: I also find metadata a super lazy solution (offering bad user experience) for a (probably) implementation issue.
I think on the long run we should consider having a look at GitLab's Pipeline Configs and get inspiration from there.

TBH, overrides is a pretty bad user experience. Reading a job definition with overrides is going to be a more brain intensive task than necessary.

Well, we still have time to change this.
How exactly is it more brain intensive task?

How exactly is it more brain intensive task?

By being redundant. Would something like this work instead?
specfile_path: fedora/package.spec
synced_files:
  - x
  - y
actions:
  post-upstream-clone: ls

jobs:
- job: build
  trigger: release
  specfile_path: somewhere/package.spec
  synced_files:
    - a
    - b
    - c
  actions:
    create-archive: ls

are we actually able to objectively decide which is "better"? (whatever "better" means here)

Probably not :smile:
How about opening an issue and pinging a few of our users what they would prefer?


Registry: Edit key upon clicking anywhere on value

It would be nice if a registry key could be edited by clicking anywhere on the value instead of only after the value. This would be particularly useful if the window is narrowed or there are keys with long entries.

Agreed. Also you can click just left of the value as well. That should always work

@joshmutus @jwenner @maffoo Did Pull #192 also fix this issue?

Can't tell. I'm strictly a Windows user, so running the dev version is an open question (#48). The only way I can provide feedback is if someone either makes available a compiled version or loads a version on matrix-reloaded. Speaking of which, the main version on matrix-reloaded doesn't even have 7b4f8a675000ab3759535b07df1d1985c5ab5c0f or any of the later changes, while the /dev/maffoo version is only on 0c80392.

Looks like this is now fixed (at least as of 280f46b), so closing.


hackrf: 2021.03.1 -> 2022.09.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/greatscottgadgets/hackrf/releases.
meta.description for hackrf is: "An open source SDR platform"
meta.homepage for hackrf is: "https://greatscottgadgets.com/hackrf/"
meta.changelog for hackrf is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2022.09.1 with grep in /nix/store/4r46fjf1q8y28jmn68aq4vjz7hkb0gw2-hackrf-2022.09.1
found 2022.09.1 in filename of file in /nix/store/4r46fjf1q8y28jmn68aq4vjz7hkb0gw2-hackrf-2022.09.1

Rebuild report (if merged into master) (click to expand)

22 total rebuild path(s)

22 package rebuild(s)

First fifty rebuilds by attrpath
cubicsdr
dump1090
gnuradio3_8Packages.ais
gnuradio3_8Packages.osmosdr
gqrx
gqrx-gr-audio
gqrx-portaudio
hackrf
kalibrate-hackrf
openwebrx
pothos
python310Packages.soapysdr-with-plugins
python39Packages.soapysdr-with-plugins
qradiolink
rtl_433
sdrangel
sdrpp
soapyhackrf
soapysdr-with-plugins
srsran
urh
welle-io

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/4r46fjf1q8y28jmn68aq4vjz7hkb0gw2-hackrf-2022.09.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A hackrf https://github.com/r-ryantm/nixpkgs/archive/58e113668a06bc68e90111b8e4a2783ff25ac7fb.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/4r46fjf1q8y28jmn68aq4vjz7hkb0gw2-hackrf-2022.09.1
ls -la /nix/store/4r46fjf1q8y28jmn68aq4vjz7hkb0gw2-hackrf-2022.09.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

22 packages built:

cubicsdr
dump1090
gnuradio3_8Packages.ais
gnuradio3_8Packages.osmosdr
gqrx
gqrx-gr-audio
gqrx-portaudio
hackrf
kalibrate-hackrf
openwebrx
pothos
python310Packages.soapysdr-with-plugins
python39Packages.soapysdr-with-plugins
qradiolink
rtl_433
sdrangel
sdrpp
soapyhackrf
soapysdr-with-plugins
srsran
urh
welle-io

Maintainer pings
cc @sjmackenzie for testing.

Result of nixpkgs-review pr 193718 run on x86_64-linux 1

22 packages built:

cubicsdr
dump1090
gnuradio3_8Packages.ais
gnuradio3_8Packages.osmosdr
gqrx
gqrx-gr-audio
gqrx-portaudio
hackrf
kalibrate-hackrf
openwebrx
pothos
python310Packages.soapysdr-with-plugins
python39Packages.soapysdr-with-plugins
qradiolink
rtl_433
sdrangel
sdrpp
soapyhackrf
soapysdr-with-plugins
srsran
urh
welle-io

Don't have hardware so cannot test any further.


Allow loading accounts via address/address conversion

Overview
Support loading account by address (example pulled from readme)
Specification
a = accounts["0x...."]  # Load by raw address
# OR
a = accounts["example.eth"]  # Load by ENS (via conversion plugin)

We are able to load by address now:
In [5]: address = "0x1e59ce931B4CFea3fe4B875411e280e173cB7A9C"

In [6]: accounts[address]
Out[6]: <KeyringAccount 0x1e59ce931B4CFea3fe4B875411e280e173cB7A9C>

^ Note: that is only an account on a local chain so not doxxing myself or anyone here

I just verified! I am totally able to load account by my ENS name when connected to the right network and all that! This is so wicked.
a = accounts["juliya.eth"]


Adding a BoundingGrid does not update inspector

When a BoundingGrid is instantiated and associated with a node it does not trigger an update of the inspector. This was observed in this case: https://github.com/scenerygraphics/scenery/issues/275

A related issue, when expanding the children of a Bounding Grid:

Within 1-2 seconds the branch collapses back into an unexpanded node


DevExp improvements

Add meshCollider check for entities with PointerEvent and print a warn if it cant be clickeable
Use width as a default value for UiEntities (useful for UiText)
Fix React.JSX type

Closes https://github.com/decentraland/sdk/issues/778


Update changelog for the 'retry-after' fix

Closes #1526

@RickWinter , not sure yet how to test that RetryPolicy does really sleep for the expected value. In C repo, we can inject mocks, not sure about here. If we want this soon, for the release, there may not be an option ready. Let's discuss later today.

At a simple level we should have tests that parse off the value of the retry header and do a retry.  You could create a custom pipeline with the retrypolicy and your response generator.  Would allow you to simulate the policy parsing the value and calling back to your response generator which can also double as validation on the retry happening.

@RickWinter , I extracted unit test update to a separate issue, #1570. I'll close #1526, because it only talks about the changelog.

/check-enforcer reset

/check-enforcer evaluate

/check-enforcer override


Add multiple themes to one package

This will need to add some new original code, so I will do that.
For now, I have a vanilla that we can push out to repositories for just the icon themes. I'm sure they can wait another 2 days ;)
lol jk. I will have it done ASAP :))

I'm hoping to remedy this by using a while loop, where as long as the user is specifying they would like to add more files to the package, it continues the prompting
adding while loop

Feature added in latest commit to build


Should recognize COPYING file as a license file

When scanning github.com/BurntSushi/toml, license finder did not find the license because it was in a COPYING file.  This is apparently a standard practice (see https://github.com/BurntSushi/toml/pull/184#issuecomment-337660728).

FYI, this library https://github.com/benbalter/licensee supports COPYING if we wanted to use that under the covers.  But realize that is a bigger change.

This should be addressed in PR #410
LF was only looking for candidate files under a src directory for Glide projects


Pass-Through inputFormatters in DropdownMenu

Pass-Through inputFormatters in DropdownMenu.
Fixes: #142374
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Linux docs test ci failure seems flaky

Hi, when is this expected to come to flutter channel stable or beta??

Master channel.


create setup with running privnet based on neo-go

To make subj we have to:

Dump 6000 or so blocks from privnet (in order to have account with Gas)
Change compose file and makefile to accept param to restore blockchain from that dump and start bc from 6000th block.

6000-privnet-blocks.acc.gz
I think these are the blocks in question.

They're corresponding to the neo-local setup where everything is owner by the AK2nJJpJr6o664CWJKi1QRXjqeic2zRp8y with a WIF of KxDgvEKzgSBPPfuVfw67oPQBSjidEiqTHURKSDL1R7yGaGYAeYnr.

To restore: ./bin/neo-go db restore -i 6000-privnet-blocks.acc

As I understand, we should run nodes in two steps:

restore from the archive if it's a clean start
running node in normal mode

I propose to add docker-entrypoint.sh like in Postgres

@fyrchik can you provide config with NeoCLI private keys?


1.14 version does not run under LocalSystem

Azure Data Studio Version:

Steps to Reproduce:

Version 1.13.1 runs fine under Local System using
Administrative Command Prompt:
Run psexec64 -i -s cmd.exe
In the new "nt authority\system" command promt:
Run "C:\Program Files\Azure Data Studio\azuredatastudio.exe"

The application starts and runs as normal.
After upgrade to 1.14, when trying this same scenario, the application starts and you can see it in the taskbar, but the UI will not activate.
Tried this on multiple machines now and same result. We have had to back down all 1.14 back to 1.13.1 in order to use Azure Data Studio

@genifycom I am not able to reproduce the issue. do you see any error in the command window or in this folder: C:\Windows\System32\config\systemprofile\AppData\Roaming\azuredatastudio\logs?

So I ran version 1.13.1 under Local System and that ran fine (run from the Command Prompt as "C:\Program Files\Azure Data Studio\azuredatastudio.exe"). Then I upgraded to 1.14.1
I ran the same command.
The command line says
update#setState idle
update#setState checking for updates
[VS Code]: detected unresponsive
Then I get a Dialog saying "The window is no longer responding" Reopen, Keep Waiting, Close
Mouse on the Azure Data Studio Icon shows [Administrator] (unresponsive)
It is definitely a permissions issue. Running from the Task Bar via the icon opens immediately.
So the test is run Administrative Command Prompt. Run psexec64 -i -s cmd.exe
In the new CMD prompt, run "C:\Program Files\Azure Data Studio\azuredatastudio.exe"
I see that Azure Data Studio does eventually open. It is taking several minutes.
Please advise if you can reproduce.

BTW, I see the log directories. Which file should I be looking at for you (there are several directories and files in there)?

@genifycom still no repro from our team. and you are saying it eventually worked after several minutes? to help understanding the issue, do you mind zipping up log files and send it to me (alanren@microsoft.com)? also do you see anything error in the Windows event viewer?

logs.zip


Fetch is Slow

Hi,
I know there are some issues open about the fetch being slow, but from what i see those issues are about when the app is in debugging mode(connected to the chrome), which is not the case.
The problem is, that when i make a request, it takes a lot of time to complete the request between point A and point B (see code), and this happen both in debug and release mode.
We are talking about 2 mega of information that is coming from the server. in PostMan the same request take 3 second counted with a timer and  1155ms counted by PostMan.
//Point A
fetch('http://api.myApi.com/mobile/', {
  method: 'GET',
  headers: {
    'Accept': 'application/json',
    'Content-Type': 'application/json',
    'Authorization': 'myToken'
  },
  body: null
}).then(res => {
  if (!res.ok) {
    throw Error(response.statusText);
  }
  //Point B
  return res.json();
})

Values in real devices from Point A to Point B:
iPhone 6s: between 4 and 14 seconds
iPhone6: between 25 and 40 seconds
iPhone 5s: >1m

React Native version: V0.31.0
Platform: iOS, (Not 100% sure about Android, i just have one android device to test, so i can't say if it is the device fault)
Operating System: MacOS
Network Info: Wi-fi, 200 mega optical fiber

@flaviotobi why you close this?
Did you found solution for this?

I understand that the problem was somewhere where the data is decoded (the response came with data very nested), so in the server side we break the information in peaces for a better decode and networking process.

I have problems with it. The fetch() function is way more faster on iOS than on Android. Does someone have an idea why?

@SamiChab  do you set gzip header?

@yury no, what do you mean with it? I suppose the API has to support it?

@SamiChab try set and see the difference
headers: {'Accept-Encoding':'gzip;q=1.0, compress;q=0.5'}

Nope, it doesn't change a lot. But I guess the error was mine: I wasn't calling exactly the same routes on iOS and Android... Thanks for your help @yury


add test correction fields to COVID-19 and SimpleReport schemas and add ability to sequence multiple NTE segments

Description
This PR adds test_correction_reason to the covid-19 schema with PII: true and mapped to NTE-3. test_correction_reason is then extended to the simple report schema. There was already a field(comment) that was mapped to NTE-3. So this PR also alters the HL7Serializer to print multiple NTE segments; one segment for each field mapped to NTE-3.
Test Steps:

./prime data --input-fake 3 --input-schema primedatainput/pdi-covid-19 --output --target-states FL
Ensure data is present for test_correction_reason in fake file
./prime data --input <OUTPUT From Step 1> --input-schema primedatainput/pdi-covid-19 --route --output-dir
check output HL7 for NTE

Changes

add test_correction_reason to covid-19.schema as TEXT mapped to NTE-3
add test_correction_reason to PrimeDataInput/pdi-covid-19.schema
add repeat sequence to NTE in formSegSpec()
add sequence value to buildMessage() with increment

Checklist
Testing

[X]  Tested locally?
[X] Ran ./prime test or ./gradlew testSmoke against local Docker ReportStream container?

Fixes
Add test_correction_reason to COVID-19 schema and SR schema #3432
Pull reviewers stats
Stats for the last 30 days:

User
Total reviews
Median time to review
Total comments

MauriceReeves-usds
30
36m
7

cwinters-usds
20
1d 15m
8

jimduff-usds
14
14h 18m
3

TomNUSDS
14
1h 15m
23

sean-usds
12
11m
3

carlosfelix2
11
5h 14m
68

brick-green-agile6
8
1h 10m
4

jorg3lopez
7
1h 52m
1

jbiskie
7
1h 9m
0

clediggins-usds
5
1h 14m
3

whytheplatypus
4
1d 21h 26m
7

JosiahSiegel
4
30m
2

RickHawesUSDS
4
3h 24m
0

sethdarragile6
4
2h 34m
0

kevinhaube
3
16h 45m
5

oslynn
3
22h 21m
21

ahay-agile6
2
1d 22h 26m
0

jeremy-page
2
10h 49m
0

rhood23699
1
1m
0

victorialb-usds
1
2d 20h 38m
1

The PR looks good! Thx.


fix(ts-sdk): correctly resolve non-primitive default value

There was an issue that created an error when a non-primitive default value was set to a function like
@object()
class Default {
  @func()
  a(
    dir: Directory = dag.directory()
      .withNewFile("/foo", "hello world")
    ): Container {
    return dag.container().withMountedDirectory("/dir", dir)
  }
}

This commit fixes the issue to ignore the default value registration if it's not a primitive type and let the TypeScript runtime resolve it during the execution.
It's a workaround to accomplish the result because resolving the value during the registration requires to run the TS code in a custom runtime that must contains all user's dependency which may be resource consumming + complex to resolve.

Needs a changelog entry.

It's a workaround to accomplish the result because resolving the value during the registration requires to run the TS code in a custom runtime that must contains all user's dependency which may be resource consumming + complex to resolve.

I didn't get this. Doesn't registration and execution run in the same runtime, with the same access to the API? Why the need for a custom runtime?

I didn't get this. Doesn't registration and execution run in the same runtime, with the same access to the API? Why the need for a custom runtime?

No it doesn't, the registration isn't executing the code, it's only doing a static analysis

Needs a changelog entry.

I added the changelog entry

I don't understand this workflow: https://github.com/dagger/dagger/actions/runs/9666769666/job/26667052999?pr=7740
My PR has a changelog :O

I didn't get this. Doesn't registration and execution run in the same runtime, with the same access to the API? Why the need for a custom runtime?

No it doesn't, the registration isn't executing the code, it's only doing a static analysis

By "registration" it's implied to be sending the Module ID with the typedefs to the API. At that point you are executing TS code and have access to the API.

By "registration" it's implied to be sending the Module ID with the typedefs to the API. At that point you are executing TS code and have access to the API.

Yes but the default value is encoded as a string, so I would need to create an equivalent so I can call the Dagger API, but what if the code is more complex than that and call an external function?
There's something in the compiler API to execute TS code but it doesn't include dependencies, and we cannot know what the default func needs to have in order to be executed, if it was loaded as an actual code instance, that would be great but it's not the case

You don't have to have the value during scan, if you can save just enough that can be used later when talking to the API. I also wonder if there's anything else from the introspection stuff that can get you something better than just the string representation. There's a lot of methods in that introspection data model from TypeScript.

I also wonder if there's anything else from the introspection stuff that can get you something better than just the string "representation". There's a lot of methods in that introspection data model from TypeScript.

Based on Chat GPT

To get the value of a default argument as its real type using the TypeScript Compiler API, you need to evaluate the initializer expression rather than just convert its type to a string. This involves interpreting the AST node corresponding to the default value.

     function evaluateExpression(node: ts.Expression): any {
       if (ts.isStringLiteral(node)) {
           return node.text;
       } else if (ts.isNumericLiteral(node)) {
           return parseFloat(node.text);
       } else if (ts.isBooleanLiteral(node)) {
           return node.kind === ts.SyntaxKind.TrueKeyword;
       } else if (ts.isArrayLiteralExpression(node)) {
           return node.elements.map(evaluateExpression);
       } else if (ts.isObjectLiteralExpression(node)) {
           const result: { [key: string]: any } = {};
           node.properties.forEach(prop => {
               if (ts.isPropertyAssignment(prop) && ts.isIdentifier(prop.name)) {
                   result[prop.name.text] = evaluateExpression(prop.initializer);
               }
           });
           return result;
       } else if (ts.isFunctionExpression(node) || ts.isArrowFunction(node)) {
           // Convert the function expression to JavaScript code
           const functionCode = node.getText();
           // Evaluate the function in a safe environment
           return evaluateFunction(functionCode);
       } else if (ts.isIdentifier(node)) {
           // Handle identifiers (e.g., variable names)
           const symbol = checker.getSymbolAtLocation(node);
           if (symbol && symbol.valueDeclaration) {
               const declaration = symbol.valueDeclaration;
               if (ts.isVariableDeclaration(declaration) && declaration.initializer) {
                   return evaluateExpression(declaration.initializer);
               }
           }
       }
       return undefined;
   }

    function evaluateFunction(functionCode: string): any {
       // Use a new Function to safely evaluate the function code
       try {
           const func = new Function(`return (${functionCode})`)();
           return func();
       } catch (error) {
           console.error('Error evaluating function:', error);
           return undefined;
       }
   }

I can try to see if I can execute the actual function but I'm not sure it will work if it's using external dependencies.

I wouldn't try to evaluate the string based expression outside of the runtime process. What I was wondering is if the TypeScript Compiler API could have enough information to would allow you you piece it together at runtime.
However, I'd explore decorators a bit more first. Moving off of the experimental decorators, and maybe using a third-party library for reflection, you could get the standard value that way, directly within the runtime process. It could even make the compiler sub-process not necessary perhaps.

To be clear, I'm not suggesting doing this now. Ok to leave things as is.


AutoKuma is not adding monitors to Uptime-Kuma

Preceding are my docker-composes for Uptime-Kuma, AutoKuma, and an example docker I'm trying to get added to Uptime Kuma. As you can see below, I can see where the tags are being generated, but AutoKuma is still not adding any monitors to Uptime-Kuma.

Hi, are the any messages in the AutoKuma log?
The first thing that comes to mind is that you are using container_name as id, which might include characters that are not valid, you should probably first slugify them like in the example:
{# Generate an autokuma id by slugifying the "container_name" #}
{% set id = container_name | slugify %}

Besides that it's hard to say anything without logs.

I don't get logs.

Hmm this is weird, are you sure the jellyseer container actually exists and is on the same docker host as autokuma?

I can absolutely confirm that the jellyseerr container exists and responds.

I have the same issue.  No errors, no logs besides the pretty logo.. I'm running a docker swarm cluster, here is an example of a service i want to monitor:
 duplicati:     image: lscr.io/linuxserver/duplicati:latest     environment:       - PUID=0       - PGID=0       - TZ=America/Chicago     volumes:       - /mnt/appdata/duplicati:/config     ports:       - :8200     deploy:       labels:         kuma.duplicati.http.name: "Duplicati"         kuma.duplicati.http.url: "http://duplicati:8200"       placement:         constraints:           - node.labels.nas-affinity == true     networks:       docker_network:
Here is kuma and autokuma composes:
`
uptime-kuma:
image: louislam/uptime-kuma
volumes:
- /mnt/appdata/uptimekuma:/app/data
ports:
- ":3001"
deploy:
placement:
constraints:
- node.labels.nas-affinity != true
networks:
docker_network:
autokuma:
image: ghcr.io/bigboot/autokuma:master
ports:
- :3001
environment:
AUTOKUMA__KUMA__URL: http://uptime-kuma:3001
AUTOKUMA__DOCKER__HOSTS: tcp://docker-socket-proxy:2375
AUTOKUMA__DOCKER__LABEL_PREFIX: kuma
networks:
docker_network:
deploy:
placement:
constraints:
- node.labels.nas-affinity != true
networks:
docker_network:
external: true
name: "containerNetwork"
`
Have tried with and without docker-socket-proxy (when I did without, I had it running on the manager)
Any suggestions?

papirov, out of curiosity, what platform are you running docker on?

4 nodes in the cluster are running on raspbian, and 1 node is on the latest Ubuntu.  Autokuma is definitely talking to Uptime-Kuma, because at the two times that UptimeKuma had to be restarted/upgraded, AutoKuma logged its unhappiness

Any chance Docker is installed as a Snap package for you, as opposed to a apt?

0 chance. All have been installed through apt.

Here are some things I can think of:

Make sure you're using the stable/latest version, not master, at least for testing
if you're using swarm, make sure the labels end up on the containers, not the services. Alternatively enable support for services in AutoKuma. Though swarm support definitely is less tested than plain Docker.

Here are some things I can think of:

Make sure you're using the stable/latest version, not master, at least for testing
if you're using swarm, make sure the labels end up on the containers, not the services. Alternatively enable support for services in AutoKuma. Though swarm support definitely is less tested than plain Docker.

My labels are definitely on services.  But I am dumb!  I needed this variable:
     AUTOKUMA__DOCKER__SOURCE: "both"
Restarted and it's working on swarm.  Woohoo!!

I don't get logs.

Same issue here!