PR template

Hey 👋🏼
Proposed change

With the recent merge of #654 and #655  I think we should also include templates for PR
Why?
Having standard templates will not only make it easier for those reviewing them to track the state of the PR but also will encourage the submitters to make sure they adhere to the contributing guidelines and make some checks before the PR is sent
Alternative options

--
Who would use this feature?

Contributors to the project
How much effort will adding it take?

Who can do this work?

Low effort -  anyone could take this as this is a non-coding activity.
I can even take this as I already have some templates that I have for personal use/projects

Sounds like a good idea. Do you want to propose one? My only experience/recommendation is that we try and keep it short and not include things in a checklist that CI can/does check for us, let's bundle those as "make sure the checks all pass" if we feel that would help people. On a previous project we had a (at the end when we decided to remove it) checklist of seven or so items and most of the time people ignored the whole list :-/

I opened a similar issue on team-compass for an org-wide template https://github.com/jupyterhub/team-compass/issues/302
(and despite intending to work on it straight away I've failed to do so....)

This also slipped my to-do list. Want to work on this together @manics ?

Definitely! How about if I open a PR on https://github.com/jupyterhub/.github/ based on the comments on https://github.com/jupyterhub/team-compass/issues/302 and we go from there?


Error in is_entity_extractor_present() in rasa/nlu/test.py

Rasa version: Rasa 1.10.23, but code also seems unchanged in master
Python version: 3.7.9
Operating system (windows, osx, ...): Linux
Issue:
is_entity_extractor_present() checks if the return of get_entity_extractors() is not an empty list.
But get_entity_extractors() returns a set, so the the comparison is always True.
Command or request that led to error:
rasa test nlu

Thanks for raising this issue, @koernerfelicia will get back to you about it soon✨
Please also check out the docs and the forum in case your issue was raised there too 🤗

@govertbuijs, thanks for raising this! This does indeed look like a bug.


Setup basic gui

This PR gets rid of the boilerplate code from the Vue quick-start command. I've added a serviceable starting point for further GUI development.

I'm still getting this default page. I think I am doing the wrong commands?
I've tried:

npm run serve
npm run build
npm install -g serve
serve -s dist

Here's the page I keep seeing. Can you let me know if I just have the command wrong on my end?

Solved previous comment by pulling your branch with "git fetch origin pull/15/head:test". Will leave my review now :)

Working on my end. I can see your new pages. No buttons should be working at the moment correct?

Yes - no functionality has been coded yet.


Allow parallel operation for multiple regions

When creating new ECR repo in multiple regions, this slows down the pipeline significantly. This PR helps save precious time every pipeline run.

Hi all,
Can I get a review on this? We have multi-regional ECRs and uploading sequentially is a bit too slow

@BEvgeniyS Thanks for the PR and apologies for the long wait. We're organising someone to review and test the changes and we'll get back to you.

@BEvgeniyS this is a good change, thanks for the work and patience.


cmdclass clash

Versioneer creates a cmdclass and requires that the setup method uses that. While this works for the majority of packages, it breaks when a package must use a different cmdclass. For example numpy defines a cmdclass. This cmdclass is also used by scipy and definitely relied upon by a bunch of other scikits -- those that follow the format specified by the scikit-example.
Specifically, the issue arises from 2 classes that Versioneer extends to create the cmdclass i.e build_py and sdist.
A solution would be to let get_cmdclass() take arguments for these base classes. i.e. having the a  signature like the following:
get_cmdclass(build_py=None, sdist=None)

Such a change should be backwards compatible.

Hm, so the Versioneer code would need to upcall to the numpy's version of e.g. build_py, instead of going directly to setuptools or distutils? And numpy is probably (internally) upcalling to setuptools's version?
Yeah, passing in arguments sounds like a decent approach to me. What if we just passed in a single "old cmdclass" dict, and if any of the overridden commands were defined in there, then Versioneer would upcall to them instead of setuptools/distutils?
I'd like to put a sample here, but I'm having trouble finding a scikit example that pulls a cmdclass from numpy. I'm guessing it would look something like this:
from setuptools import setup
import versioneer
from numpy import something
numpy_cmdclass = something.get_cmdclass()
cmdclass = versioneer.get_cmdclass(numpy_cmdclass)
setup(..., cmdclass=cmdclass)

Using an "old cmdclass" is a better approach.
For numpy cmdclass examples, it is not straight forward to discern when browsing the setup.py files. The line to look out for is:
from numpy.distutils.core import setup

You can see it in the scikit-example or even scipy.
The setup function from numpy updates the numpy cmdclass.
I will submit a PR.


Option to disable onTap behaviour

Hey DevNico, this is a really cool flutter package. Maybe you could add an option to disable the onTap behaviour of the widget. In my project i tried to put the breadcrumb inside a button. I didnt want the 'expand' behaviour so i wrapped it with another GestureDetector (HitTestBehavior.opaque) but it still triggered the breadcrumb GestureDetector. At the end i had to wrap it with
Listener(
      behavior: HitTestBehavior.opaque,
      onPointerDown: ...
      ...
)

Apperently this is faster https://stackoverflow.com/questions/53063021/flutter-tap-delay-with-gesturedetector-in-a-tile-of-a-gridview/53063398#53063398.
Cheers!

Added an option to disable the expansion behaviour in v0.1.0 see https://pub.dev/packages/breadcrumbs


The Social media Handles are not is visible position

In the side bar the social media handle are places behind the other options i will make the seperate sections in the side bar to show all social media handles properly. Will you assign work to me.

@Abhilash107  Kindly respond to me so i can start work on it

@Abhilash107  Kindly respond to me so i can start work on it

Kindly check the announcement in discussion tab.

@Abhilash107  Kindly respond to me so i can start work on it

Kindly check the announcement in discussion tab.


EPSG Codes on front end

In 2018 when we designed the API DB, the Projections Look Up table was designed to be just the number for the EPSG Code. And on the front end we would add the web site https://epsg.io in front of the number and create an href to that site, ex https://epsg.io/3857. This would all the user to get the technical details of each CRS.
Currently we are just showing a number in this part of the front end. Not all user may know what these numbers mean.

If we no longer want to href out to EPSG.io, should we consider using a common name or abbreviation. This would require a model change.

I don't have a problem referencing out to epsg.io
I'll look at how many different spatial references we use. I could add a new column then convert the codes over to a String Like WGS84 then swap out the columns in the model and do it in bulk.
@ThorTheDestroyer @mitchellryant Those are two options. Let me know what you guys think.
I'm going to wait until @ctrepka @TWDBrob @twdbben and @DipakS28 get back to discuss it with them and see if it's used as a foreign key or something important though. first so it won't be done until next week.

Completed in pull request #68 and #69
Decided to go with "por que no los dos?" (Why not both?)
Human readable format is shown and it creates a hyperlink to epsg.io ex: WGS84


[FSDE-1430] Updated Lodash, Marked, PrismJS, Pug dependencies

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-130/1/. :white_check_mark:

You can check this PRs instance in https://118850ae71761360bbffb1d453f266330745f590-chi-pr.enterprise.ctl.io

You can check this PRs instance in https://7d56bae862929d168c9b20aca2fb9bd8e362d990-chi-pr.enterprise.ctl.io

@evansito @josecarlosgonzalezv please review

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-130/3/. :white_check_mark:

You can check this PRs instance in https://0cc70a52e8b31307974752fbe6ccefa09942e3b3-chi-pr.enterprise.ctl.io

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-130/4/. :white_check_mark:

You can check this PRs instance in https://ef1b1454876bec645b27aac8b2bf009e61c143a4-chi-pr.enterprise.ctl.io

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-130/5/. :white_check_mark:

You can check this PRs instance in https://0ed87e3914afd0999e73e26489f5d2fab76b4a8b-chi-pr.enterprise.ctl.io

The CI pipeline did not run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-130/6/. :x:

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-130/7/. :white_check_mark:

You can check this PRs instance in https://c54b1188592f6e2a2a3ec6032d94ef442cc1649e-chi-pr.enterprise.ctl.io

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-130/8/. :white_check_mark:

You can check this PRs instance in https://c54b1188592f6e2a2a3ec6032d94ef442cc1649e-chi-pr.enterprise.ctl.io

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-130/9/. :white_check_mark:

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-130/10/. :white_check_mark:

You can check this PRs instance in https://7da246f455d8af28a05c94e7fc85028cc92ff9b4-chi-pr.enterprise.ctl.io

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-130/11/. :white_check_mark:

You can check this PRs instance in https://43551aced7d245bf047ae68d6a336d1a7d16c750-chi-pr.enterprise.ctl.io

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-130/12/. :white_check_mark:

You can check this PRs instance in https://13fe4b39336943e2cbf5d2ccdc24573db87da809-chi-pr.enterprise.ctl.io

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-130/13/. :white_check_mark:

You can check this PRs instance in https://58c0ed71be61b163e8200dd42caf693f5a4a5920-chi-pr.enterprise.ctl.io

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-130/14/. :white_check_mark:

You can check this PRs instance in https://a370706ab78a653f14c8bca4b36475dc95d83d3d-chi-pr.enterprise.ctl.io


Use fixed buffer size when reading variable length messages

Instead of using the size defined by the RPC message for the read buffer, use a fixed size to avoid overflows.
Tests are going to be included on the Teleport side.

sonatype's nancy reported this as a vulnerability in one of my projects.
@gabrielcorado can this change be upstreamed to https://github.com/denisenkom/go-mssqldb?
$ go list -json -m all | nancy sleuth
<EMAIL_ADDRESS>1 known vulnerabilities affecting installed version
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ 1 vulnerability found                                                                            ┃
┣━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
┃ Description        ┃ 1 non-CVE vulnerability found. To see more details, please create a free    ┃
┃                    ┃ account at https://ossindex.sonatype.org/ and request for this information  ┃
┃                    ┃ using your registered account                                               ┃
┣━━━━━━━━━━━━━━━━━━━━╋━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
┃ OSS Index ID       ┃ sonatype-2023-1010                                                          ┃
┣━━━━━━━━━━━━━━━━━━━━╋━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
┃ CVSS Score         ┃ 6.5/10 (Medium)                                                             ┃
┣━━━━━━━━━━━━━━━━━━━━╋━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
┃ CVSS Vector        ┃ CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L                                ┃
┣━━━━━━━━━━━━━━━━━━━━╋━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
┃ Link for more info ┃ https://ossindex.sonatype.org/vulnerability/sonatype-2023-1010              ┃
┗━━━━━━━━━━━━━━━━━━━━┻━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
1 Vulnerable Packages
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Summary                      ┃
┣━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━┫
┃ Audited Dependencies    ┃ 54 ┃
┣━━━━━━━━━━━━━━━━━━━━━━━━━╋━━━━┫
┃ Vulnerable Dependencies ┃ 1  ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━┻━━━━┛
Cleaning up project directory and file based variables
00:01
ERROR: Job failed: exit code 1


Miserable reliability with macos-14 runners

Description
Over the last ~1 month, the macos-14 runners reliability has seriously degraded. We have used them since March, and used to have relatively no issues. We have absolutely no issues with our self-hosted macOS intel runner, so I am about to do the same for apple silicon.

hdiutil issues during builds for macOS app, seemingly caused by these issues (#10511, #7522)
Random, bizarre issues while bundling javascript for an electron app that magically fix themselves after rerunning the workflow, sometimes it takes 5-6 times of rerunning to get it to work.

'\x1B[36mvite v5.4.7 \x1B[32mbuilding SSR bundle for production...\x1B[36m\x1B[39m\n' +
    'transforming...\n' +
    '\x1B[32m✓\x1B[39m 298 modules transformed.\n' +
    'rendering chunks...\n' +
    '\x1B[2mout/main/\x1B[22m\x1B[2mchunks/\x1B[22m\x1B[36mHashUtils.renderer-hSXnO4Rp.js  \x1B[39m\x1B[1m\x1B[2m  0.36 kB\x1B[22m\x1B[1m\x1B[22m\x1B[2m │ map:     0.89 kB\x1B[22m\n' +
    '\x1B[2mout/main/\x1B[22m\x1B[2mchunks/\x1B[22m\x1B[36mwriteAtomicFile-CEaw96OJ.js     \x1B[39m\x1B[1m\x1B[2m  2.19 kB\x1B[22m\x1B[1m\x1B[22m\x1B[2m │ map:    10.04 kB\x1B[22m\n' +
    '\x1B[2mout/main/\x1B[22m\x1B[2mchunks/\x1B[22m\x1B[36mJsonCrypto-CFMBjItk.js          \x1B[39m\x1B[1m\x1B[2m  2.56 kB\x1B[22m\x1B[1m\x1B[22m\x1B[2m │ map:     4.11 kB\x1B[22m\n' +
    '\x1B[2mout/main/\x1B[22m\x1B[36mindex.js                               \x1B[39m\x1B[1m\x1B[2m482.18 kB\x1B[22m\x1B[1m\x1B[22m\x1B[2m │ map: 1,638.00 kB\x1B[22m\n' +
    '\x1B[32m✓ built in 3.38s\x1B[39m\n' +
    '\x1B[36mvite v5.4.7 \x1B[32mbuilding SSR bundle for production...\x1B[36m\x1B[39m\n' +
    'transforming...\n' +
    '\x1B[32m✓\x1B[39m 11 modules transformed.\n' +
    'rendering chunks...\n' +
    '\x1B[2mout/preload/\x1B[22m\x1B[36minternal.js     \x1B[39m\x1B[1m\x1B[2m 0.71 kB\x1B[22m\x1B[1m\x1B[22m\x1B[2m │ map:  2.47 kB\x1B[22m\n' +
    '\x1B[2mout/preload/\x1B[22m\x1B[36melectron.js     \x1B[39m\x1B[1m\x1B[2m 2.37 kB\x1B[22m\x1B[1m\x1B[22m\x1B[2m │ map:  8.86 kB\x1B[22m\n' +
    '\x1B[2mout/preload/\x1B[22m\x1B[36mapp-runtime.js  \x1B[39m\x1B[1m\x1B[2m17.54 kB\x1B[22m\x1B[1m\x1B[22m\x1B[2m │ map: 57.18 kB\x1B[22m\n' +
    '\x1B[32m✓ built in 530ms\x1B[39m\n' +
    '\x1B[36mvite v5.4.7 \x1B[32mbuilding for production...\x1B[36m\x1B[39m\n' +
    'transforming...\n' +
    '\x1B[32m✓\x1B[39m 4767 modules transformed.\n' +
    'rendering chunks...\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[32msplash.html                                      \x1B[39m\x1B[1m\x1B[2m    1.67 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[32mfullscreen-overlay.html                          \x1B[39m\x1B[1m\x1B[2m    2.33 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[32mbase.html                                        \x1B[39m\x1B[1m\x1B[2m    3.38 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Size3-Regular-CTq5MqoE.woff         \x1B[39m\x1B[1m\x1B[2m    4.42 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Size4-Regular-Dl5lxZxV.woff2        \x1B[39m\x1B[1m\x1B[2m    4.93 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Size2-Regular-Dy4dx90m.woff2        \x1B[39m\x1B[1m\x1B[2m    5.21 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Size1-Regular-mCD8mA8B.woff2        \x1B[39m\x1B[1m\x1B[2m    5.47 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Size4-Regular-BF-4gkZK.woff         \x1B[39m\x1B[1m\x1B[2m    5.98 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Size2-Regular-oD1tc_U0.woff         \x1B[39m\x1B[1m\x1B[2m    6.19 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Size1-Regular-C195tn64.woff         \x1B[39m\x1B[1m\x1B[2m    6.50 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Caligraphic-Regular-Di6jR-x-.woff2  \x1B[39m\x1B[1m\x1B[2m    6.91 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Caligraphic-Bold-Dq_IR9rO.woff2     \x1B[39m\x1B[1m\x1B[2m    6.91 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Size3-Regular-DgpXs0kz.ttf          \x1B[39m\x1B[1m\x1B[2m    7.59 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Caligraphic-Regular-CTRA-rTL.woff   \x1B[39m\x1B[1m\x1B[2m    7.66 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Caligraphic-Bold-BEiXGLvX.woff      \x1B[39m\x1B[1m\x1B[2m    7.72 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Script-Regular-D3wIWfF6.woff2       \x1B[39m\x1B[1m\x1B[2m    9.64 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_SansSerif-Regular-DDBCnlJ7.woff2    \x1B[39m\x1B[1m\x1B[2m   10.34 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Size4-Regular-DWFBv043.ttf          \x1B[39m\x1B[1m\x1B[2m   10.36 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Script-Regular-D5yQViql.woff        \x1B[39m\x1B[1m\x1B[2m   10.59 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Fraktur-Regular-CTYiF6lA.woff2      \x1B[39m\x1B[1m\x1B[2m   11.32 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Fraktur-Bold-CL6g_b3V.woff2         \x1B[39m\x1B[1m\x1B[2m   11.35 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Size2-Regular-B7gKUWhC.ttf          \x1B[39m\x1B[1m\x1B[2m   11.51 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_SansSerif-Italic-C3H0VqGB.woff2     \x1B[39m\x1B[1m\x1B[2m   12.03 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_SansSerif-Bold-D1sUS0GD.woff2       \x1B[39m\x1B[1m\x1B[2m   12.22 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Size1-Regular-Dbsnue_I.ttf          \x1B[39m\x1B[1m\x1B[2m   12.23 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_SansSerif-Regular-CS6fqUqJ.woff     \x1B[39m\x1B[1m\x1B[2m   12.32 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Caligraphic-Regular-wX97UBjC.ttf    \x1B[39m\x1B[1m\x1B[2m   12.34 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Caligraphic-Bold-ATXxdsX0.ttf       \x1B[39m\x1B[1m\x1B[2m   12.37 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Fraktur-Regular-Dxdc4cR9.woff       \x1B[39m\x1B[1m\x1B[2m   13.21 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Fraktur-Bold-BsDP51OF.woff          \x1B[39m\x1B[1m\x1B[2m   13.30 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Typewriter-Regular-CO6r4hn1.woff2   \x1B[39m\x1B[1m\x1B[2m   13.57 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_SansSerif-Italic-DN2j7dab.woff      \x1B[39m\x1B[1m\x1B[2m   14.11 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_SansSerif-Bold-DbIhKOiC.woff        \x1B[39m\x1B[1m\x1B[2m   14.41 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Typewriter-Regular-C0xS9mPB.woff    \x1B[39m\x1B[1m\x1B[2m   16.03 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Math-BoldItalic-CZnvNsCZ.woff2      \x1B[39m\x1B[1m\x1B[2m   16.40 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Math-Italic-t53AETM-.woff2          \x1B[39m\x1B[1m\x1B[2m   16.44 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Script-Regular-C5JkGWo-.ttf         \x1B[39m\x1B[1m\x1B[2m   16.65 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-BoldItalic-DxDJ3AOS.woff2      \x1B[39m\x1B[1m\x1B[2m   16.78 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-Italic-NWA7e6Wa.woff2          \x1B[39m\x1B[1m\x1B[2m   16.99 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Math-BoldItalic-iY-2wyZ7.woff       \x1B[39m\x1B[1m\x1B[2m   18.67 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Math-Italic-DA0__PXp.woff           \x1B[39m\x1B[1m\x1B[2m   18.75 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-BoldItalic-SpSLRI95.woff       \x1B[39m\x1B[1m\x1B[2m   19.41 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_SansSerif-Regular-BNo7hRIc.ttf      \x1B[39m\x1B[1m\x1B[2m   19.44 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Fraktur-Regular-CB_wures.ttf        \x1B[39m\x1B[1m\x1B[2m   19.57 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Fraktur-Bold-BdnERNNW.ttf           \x1B[39m\x1B[1m\x1B[2m   19.58 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-Italic-BMLOBm91.woff           \x1B[39m\x1B[1m\x1B[2m   19.68 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_SansSerif-Italic-YYjJ1zSn.ttf       \x1B[39m\x1B[1m\x1B[2m   22.36 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_SansSerif-Bold-CFMepnvq.ttf         \x1B[39m\x1B[1m\x1B[2m   24.50 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-Bold-Cx986IdX.woff2            \x1B[39m\x1B[1m\x1B[2m   25.32 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-Regular-B22Nviop.woff2         \x1B[39m\x1B[1m\x1B[2m   26.27 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Typewriter-Regular-D3Ib7_Hf.ttf     \x1B[39m\x1B[1m\x1B[2m   27.56 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_AMS-Regular-BQhdFMY1.woff2          \x1B[39m\x1B[1m\x1B[2m   28.08 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-Bold-Jm3AIy58.woff             \x1B[39m\x1B[1m\x1B[2m   29.91 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-Regular-Dr94JaBh.woff          \x1B[39m\x1B[1m\x1B[2m   30.77 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Math-BoldItalic-B3XSjfu4.ttf        \x1B[39m\x1B[1m\x1B[2m   31.20 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Math-Italic-flOr_0UB.ttf            \x1B[39m\x1B[1m\x1B[2m   31.31 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-BoldItalic-DzxPMmG6.ttf        \x1B[39m\x1B[1m\x1B[2m   32.97 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_AMS-Regular-DMm9YOAa.woff           \x1B[39m\x1B[1m\x1B[2m   33.52 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-Italic-3WenGoN9.ttf            \x1B[39m\x1B[1m\x1B[2m   33.58 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-Bold-waoOVXN0.ttf              \x1B[39m\x1B[1m\x1B[2m   51.34 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-Regular-ypZvNtVU.ttf           \x1B[39m\x1B[1m\x1B[2m   53.58 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mFullDiskAccess-B5uxDzHu.png               \x1B[39m\x1B[1m\x1B[2m   56.45 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_AMS-Regular-DRggAlZN.ttf            \x1B[39m\x1B[1m\x1B[2m   63.63 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[35mfullscreen-overlay-BilsSMWy.css           \x1B[39m\x1B[1m\x1B[2m   28.45 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[36m__vite-browser-external-BjGS5_Dj.js       \x1B[39m\x1B[1m\x1B[2m    0.22 kB\x1B[22m\x1B[1m\x1B[22m\x1B[2m │ map: '... 5001 more characters,
  stderr: '\x1B[1m\x1B[33m[plugin:vite:resolve]\x1B[39m\x1B[22m \x1B[33m[plugin vite:resolve] Module "crypto" has been externalized for browser compatibility, imported by "/private/var/folders/0g/hj_q_pzx65bbjnslxz9n0src0000gn/T/highlight-electron-temp/standalone/src/shared/ipc/ProcessWideEvents.ts". See https://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.\x1B[39m\n' +
    '\x1B[1m\x1B[33m[plugin:vite:resolve]\x1B[39m\x1B[22m \x1B[33m[plugin vite:resolve] Module "util" has been externalized for browser compatibility, imported by "/private/var/folders/0g/hj_q_pzx65bbjnslxz9n0src0000gn/T/highlight-electron-temp/standalone/node_modules/handlebars-utils/index.js". See https://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.\x1B[39m\n' +
    "node_modules/framer-motion/dist/es/components/AnimatePresence/index.mjs (1:0): Error when using sourcemap for reporting an error: Can't resolve original location of error.\n" +
    "node_modules/framer-motion/dist/es/motion/index.mjs (1:0): Error when using sourcemap for reporting an error: Can't resolve original location of error.\n" +
    '\x1B[1m\x1B[33m[plugin:vite:resolve]\x1B[39m\x1B[22m \x1B[33m[plugin vite:resolve] Module "stream" has been externalized for browser compatibility, imported by "/private/var/folders/0g/hj_q_pzx65bbjnslxz9n0src0000gn/T/highlight-electron-temp/standalone/node_modules/handlebars-async-helpers/helpers/each.js". See https://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.\x1B[39m\n' +
    '\x1B[1m\x1B[33m[plugin:vite:resolve]\x1B[39m\x1B[22m \x1B[33m[plugin vite:resolve] Module "crypto" has been externalized for browser compatibility, imported by "/private/var/folders/0g/hj_q_pzx65bbjnslxz9n0src0000gn/T/highlight-electron-temp/standalone/src/main/utils/crypto/JsonCrypto.ts". See https://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.\x1B[39m\n' +
    '\x1B[1m\x1B[33m[plugin:vite:resolve]\x1B[39m\x1B[22m \x1B[33m[plugin vite:resolve] Module "fs" has been externalized for browser compatibility, imported by "/private/var/folders/0g/hj_q_pzx65bbjnslxz9n0src0000gn/T/highlight-electron-temp/standalone/src/shared/utils/StringUtils.ts". See https://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.\x1B[39m\n' +
    'node_modules/mammoth/node_modules/bluebird/js/release/util.js (201:9): Use of eval in "node_modules/mammoth/node_modules/bluebird/js/release/util.js" is strongly discouraged as it poses security risks and may cause issues with minification.\n'
}

At this point they are borderline unusable, having to manually delete xcode and iOS simulators just for the drive to have free space is a bit insane. And even with that, random failures that are not addressable by code or config changes frequently occur.
Platforms affected

[ ] Azure DevOps
[X] GitHub Actions - Standard Runners
[ ] GitHub Actions - Larger Runners

Runner images affected

[ ] Ubuntu 20.04
[ ] Ubuntu 22.04
[ ] Ubuntu 24.04
[ ] macOS 12
[ ] macOS 13
[ ] macOS 13 Arm64
[ ] macOS 14
[X] macOS 14 Arm64
[ ] Windows Server 2019
[ ] Windows Server 2022

Image version and build link
Image: macos-14-arm64
Version: 20240918.8
Included Software: https://github.com/actions/runner-images/blob/macos-14-arm64/20240918.8/images/macos/macos-14-arm64-Readme.md
Image Release: https://github.com/actions/runner-images/releases/tag/macos-14-arm64%2F20240918.8
Not public, but here is a link:
https://github.com/highlight-ing/highlight/actions/runs/11022480898/job/30613014291
Is it regression?
Yes.
https://github.com/highlight-ing/highlight/actions/runs/11021711293/job/30609399929
Image: macos-14-arm64
Version: 20240918.8
Included Software: https://github.com/actions/runner-images/blob/macos-14-arm64/20240918.8/images/macos/macos-14-arm64-Readme.md
Image Release: https://github.com/actions/runner-images/releases/tag/macos-14-arm64%2F20240918.8
Expected behavior
Builds should reliably work and not randomly throw errors that go away when you re-run them half a dozen times.
Actual behavior
I play russian roulette with github actions to see if my builds work or if I need to spend 4 hours re-running until it does.
Repro steps
No reliable reproduction. It just happens sometimes (regularly) while building an electron app for macOS arm64 using electron-builder.

Hey @Galkon!
Latest image version runners will provide more precious space to run your builds. And, if I understand correctly how chunks rendering works, it should resolve your issue. I don't see a clear reason for the crash in this log, but most likely the process didn't have enough disk space or other resources (which is less likely) to complete.
Considering that the project is not public, I will not be able to get enough information for a quality investigation - we do not have access to private runs. I suggest waiting for the end of the release and trying your build on the new runner. Will you be able to conduct a couple of test launches on Thursday or Friday (deployment should take not less than 15 hours) and share the results with us?

Hey @Galkon!
Latest image version runners will provide more precious space to run your builds. And, if I understand correctly how chunks rendering works, it should resolve your issue. I don't see a clear reason for the crash in this log, but most likely the process didn't have enough disk space or other resources (which is less likely) to complete. Considering that the project is not public, I will not be able to get enough information for a quality investigation - we do not have access to private runs. I suggest waiting for the end of the release and trying your build on the new runner. Will you be able to conduct a couple of test launches on Thursday or Friday (deployment should take not less than 15 hours) and share the results with us?

Thanks for the swift response! Happy to be your guinea pig. Thursday and Friday we are typically doing releases anyways.

I know adding a +1 to an issue is typically not a great practice but this also seriously impacts our private builds.
I had filed a ticket with github support: https://support.github.com/ticket/personal/0/2996091
The response gave no indication as to why the reliability had changed, or what changes were made that might have caused it.
This had affected one of our 4 macos workflows, now affects 2, to the point that they never pass.
As part of our debugging, we confirmed that macos-latest-large had the issue, and hadn't changed to apple silicon nor had the OS build changed between previous successful one and now.
When they do fail, there's 2 possible outcomes:

The run is marked as cancelled, and the workflow logs miss the logs from the last step, even though you can see them streaming at run time
The run is makred as skipped, even though the run does attempt to run

In both cases, the workflow time breakdown for the macos runner always caps out just over 30m, even though the step execution time (if available) doesn't align with that. The "instability" and attention by support has gotten to the point of considering a different vendor for mac-os based CI builds.
If possible, please also include me on the test runs on thursday/friday. Happy to grant support access to our private repo as well for help debugging, or hop on a call to debug further.

Hey @Galkon!

macOS-14 images without visionOS on board rolled out. It made free plenty of precious GB.
Please check on the workflows mentioned state and come back to us with the updates. 🙇

Hey @nsheaps!
I'm not sure that your problem and the original problem stated in the issue are related. It's hard to deny such a possibility without logs, examples and a test project, yes. But the description doesn't really match up. If you think that the problem was related to disk space, then the last completed update should have solved it for you. But based on the description, I can say that it looks more like your workflow has exhausted the runner's resources. I can't say for sure without a workflow example and links to successful and unsuccessful launches - then I can at least track the version of the image used and the connection between the updates of the software used and the crashes.

Hey @Galkon!

macOS-14 images without visionOS on board rolled out. It made free plenty of precious GB.

Please check on the workflows mentioned state and come back to us with the updates. 🙇

Thanks for the update. We will be running several builds throughout today and tomorrow, I will let you know if I run into any issues.

I think in some way it is related, as we had stable performance prior, then some change was made and then our workflows started failing in weird ways.

But based on the description, I can say that it looks more like your workflow has exhausted the runner's resources.

We did note that disk space usage (measured by du and df) went above the documented thresholds, but if that were to be the case, we built a known working commit prior and it still failed, potentially due to the visionOS changes in the macos image. We'll give our workflows a shot again with macos-latest-large and macos-14-large and see if they've recovered after this change.
I think it's also somewhat important to note that this affected multiple workflows, not just the ones with high disk usage, so we'll give those a shot too. We've also documented internally to look for other mechanisms as the disk usage is coming from running our entire stack on the runner itself so we can run e2e tests with playwright, which isn't a lightweight task, but unfortunately that move is not a quick one to make.
I'll report back later today with the results of our testing. If it ends up not working still, I'm happy to toss any info your way either here or in a new ticket.
Appreciate the updates and attention here @erik-bershel !

@nsheaps 👋
Just to be on the same page. The only notable difference from productivity perspective between macos-14 and macos-14-xlarge is threads and RAM amount. And there is no difference between macos-latest-large and macos-14-large - it's the same image, just different labels/tags, the same is applicable for macos-latest and macos-14. The difference between macos-14(latest)-xlarge and macos-14(latest)-large might be found here: https://docs.github.com/en/actions/using-github-hosted-runners/using-larger-runners/about-larger-runners#about-macos-larger-runners
If your problems were specifically related to disk space (before the current release, this problem was common to all macOS-14 based images, especially arm64 based macOS-14). As of today, we have freed up a huge amount of space, which should have eliminated this problem. I expect that this should solve the problem that was originally described in the issue - chunk baking is a procedure that is quite sensitive to disk space.
At the same time, I am not aware of any other major issues that have been discovered recently that could lead to blocking your workflows. Accordingly, some other incompatibility or problem may be discovered here (perhaps your builds block the runner due to other resources or the number of disk requests, which leads to the machine hanging and the connection being broken, which could have been caused by updates to packages that participate in the build). To investigate such cases, we always need a lot of information. So far, it is not enough even to make assumptions.

@erik-bershel it looks like we are still having issues.

The issue is the chunking issue mentioned in prior posts.
    '\x1B[36mvite v5.4.8 \x1B[32mbuilding SSR bundle for production...\x1B[36m\x1B[39m\n' +
    'transforming...\n' +
    '\x1B[32m✓\x1B[39m 294 modules transformed.\n' +
    'rendering chunks...\n' +
    '\x1B[2mout/main/\x1B[22m\x1B[2mchunks/\x1B[22m\x1B[36mHashUtils.renderer-hSXnO4Rp.js  \x1B[39m\x1B[1m\x1B[2m  0.36 kB\x1B[22m\x1B[1m\x1B[22m\x1B[2m │ map:     0.89 kB\x1B[22m\n' +
    '\x1B[2mout/main/\x1B[22m\x1B[2mchunks/\x1B[22m\x1B[36mwriteAtomicFile-CEaw96OJ.js     \x1B[39m\x1B[1m\x1B[2m  2.19 kB\x1B[22m\x1B[1m\x1B[22m\x1B[2m │ map:    10.04 kB\x1B[22m\n' +
    '\x1B[2mout/main/\x1B[22m\x1B[2mchunks/\x1B[22m\x1B[36mJsonCrypto-ByPgB7sW.js          \x1B[39m\x1B[1m\x1B[2m  2.56 kB\x1B[22m\x1B[1m\x1B[22m\x1B[2m │ map:     4.11 kB\x1B[22m\n' +
    '\x1B[2mout/main/\x1B[22m\x1B[36mindex.js                               \x1B[39m\x1B[1m\x1B[2m475.80 kB\x1B[22m\x1B[1m\x1B[22m\x1B[2m │ map: 1,607.65 kB\x1B[22m\n' +
    '\x1B[32m✓ built in 3.47s\x1B[39m\n' +
    '\x1B[36mvite v5.4.8 \x1B[32mbuilding SSR bundle for production...\x1B[36m\x1B[39m\n' +
    'transforming...\n' +
    '\x1B[32m✓\x1B[39m 11 modules transformed.\n' +
    'rendering chunks...\n' +
    '\x1B[2mout/preload/\x1B[22m\x1B[36minternal.js     \x1B[39m\x1B[1m\x1B[2m 0.71 kB\x1B[22m\x1B[1m\x1B[22m\x1B[2m │ map:  2.47 kB\x1B[22m\n' +
    '\x1B[2mout/preload/\x1B[22m\x1B[36melectron.js     \x1B[39m\x1B[1m\x1B[2m 2.37 kB\x1B[22m\x1B[1m\x1B[22m\x1B[2m │ map:  8.86 kB\x1B[22m\n' +
    '\x1B[2mout/preload/\x1B[22m\x1B[36mapp-runtime.js  \x1B[39m\x1B[1m\x1B[2m17.78 kB\x1B[22m\x1B[1m\x1B[22m\x1B[2m │ map: 57.81 kB\x1B[22m\n' +
    '\x1B[32m✓ built in 330ms\x1B[39m\n' +
    '\x1B[36mvite v5.4.8 \x1B[32mbuilding for production...\x1B[36m\x1B[39m\n' +
    'transforming...\n' +
    '\x1B[32m✓\x1B[39m 4773 modules transformed.\n' +
    'rendering chunks...\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[32msplash.html                                      \x1B[39m\x1B[1m\x1B[2m    1.67 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[32mfullscreen-overlay.html                          \x1B[39m\x1B[1m\x1B[2m    2.33 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[32mbase.html                                        \x1B[39m\x1B[1m\x1B[2m    3.38 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Size3-Regular-CTq5MqoE.woff         \x1B[39m\x1B[1m\x1B[2m    4.42 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Size4-Regular-Dl5lxZxV.woff2        \x1B[39m\x1B[1m\x1B[2m    4.93 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Size2-Regular-Dy4dx90m.woff2        \x1B[39m\x1B[1m\x1B[2m    5.21 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Size1-Regular-mCD8mA8B.woff2        \x1B[39m\x1B[1m\x1B[2m    5.47 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Size4-Regular-BF-4gkZK.woff         \x1B[39m\x1B[1m\x1B[2m    5.98 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Size2-Regular-oD1tc_U0.woff         \x1B[39m\x1B[1m\x1B[2m    6.19 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Size1-Regular-C195tn64.woff         \x1B[39m\x1B[1m\x1B[2m    6.50 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Caligraphic-Regular-Di6jR-x-.woff2  \x1B[39m\x1B[1m\x1B[2m    6.91 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Caligraphic-Bold-Dq_IR9rO.woff2     \x1B[39m\x1B[1m\x1B[2m    6.91 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Size3-Regular-DgpXs0kz.ttf          \x1B[39m\x1B[1m\x1B[2m    7.59 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Caligraphic-Regular-CTRA-rTL.woff   \x1B[39m\x1B[1m\x1B[2m    7.66 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Caligraphic-Bold-BEiXGLvX.woff      \x1B[39m\x1B[1m\x1B[2m    7.72 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Script-Regular-D3wIWfF6.woff2       \x1B[39m\x1B[1m\x1B[2m    9.64 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_SansSerif-Regular-DDBCnlJ7.woff2    \x1B[39m\x1B[1m\x1B[2m   10.34 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Size4-Regular-DWFBv043.ttf          \x1B[39m\x1B[1m\x1B[2m   10.36 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Script-Regular-D5yQViql.woff        \x1B[39m\x1B[1m\x1B[2m   10.59 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Fraktur-Regular-CTYiF6lA.woff2      \x1B[39m\x1B[1m\x1B[2m   11.32 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Fraktur-Bold-CL6g_b3V.woff2         \x1B[39m\x1B[1m\x1B[2m   11.35 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Size2-Regular-B7gKUWhC.ttf          \x1B[39m\x1B[1m\x1B[2m   11.51 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_SansSerif-Italic-C3H0VqGB.woff2     \x1B[39m\x1B[1m\x1B[2m   12.03 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_SansSerif-Bold-D1sUS0GD.woff2       \x1B[39m\x1B[1m\x1B[2m   12.22 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Size1-Regular-Dbsnue_I.ttf          \x1B[39m\x1B[1m\x1B[2m   12.23 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_SansSerif-Regular-CS6fqUqJ.woff     \x1B[39m\x1B[1m\x1B[2m   12.32 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Caligraphic-Regular-wX97UBjC.ttf    \x1B[39m\x1B[1m\x1B[2m   12.34 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Caligraphic-Bold-ATXxdsX0.ttf       \x1B[39m\x1B[1m\x1B[2m   12.37 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Fraktur-Regular-Dxdc4cR9.woff       \x1B[39m\x1B[1m\x1B[2m   13.21 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Fraktur-Bold-BsDP51OF.woff          \x1B[39m\x1B[1m\x1B[2m   13.30 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Typewriter-Regular-CO6r4hn1.woff2   \x1B[39m\x1B[1m\x1B[2m   13.57 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_SansSerif-Italic-DN2j7dab.woff      \x1B[39m\x1B[1m\x1B[2m   14.11 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_SansSerif-Bold-DbIhKOiC.woff        \x1B[39m\x1B[1m\x1B[2m   14.41 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Typewriter-Regular-C0xS9mPB.woff    \x1B[39m\x1B[1m\x1B[2m   16.03 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Math-BoldItalic-CZnvNsCZ.woff2      \x1B[39m\x1B[1m\x1B[2m   16.40 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Math-Italic-t53AETM-.woff2          \x1B[39m\x1B[1m\x1B[2m   16.44 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Script-Regular-C5JkGWo-.ttf         \x1B[39m\x1B[1m\x1B[2m   16.65 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-BoldItalic-DxDJ3AOS.woff2      \x1B[39m\x1B[1m\x1B[2m   16.78 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-Italic-NWA7e6Wa.woff2          \x1B[39m\x1B[1m\x1B[2m   16.99 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Math-BoldItalic-iY-2wyZ7.woff       \x1B[39m\x1B[1m\x1B[2m   18.67 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Math-Italic-DA0__PXp.woff           \x1B[39m\x1B[1m\x1B[2m   18.75 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-BoldItalic-SpSLRI95.woff       \x1B[39m\x1B[1m\x1B[2m   19.41 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_SansSerif-Regular-BNo7hRIc.ttf      \x1B[39m\x1B[1m\x1B[2m   19.44 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Fraktur-Regular-CB_wures.ttf        \x1B[39m\x1B[1m\x1B[2m   19.57 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Fraktur-Bold-BdnERNNW.ttf           \x1B[39m\x1B[1m\x1B[2m   19.58 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-Italic-BMLOBm91.woff           \x1B[39m\x1B[1m\x1B[2m   19.68 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_SansSerif-Italic-YYjJ1zSn.ttf       \x1B[39m\x1B[1m\x1B[2m   22.36 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_SansSerif-Bold-CFMepnvq.ttf         \x1B[39m\x1B[1m\x1B[2m   24.50 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-Bold-Cx986IdX.woff2            \x1B[39m\x1B[1m\x1B[2m   25.32 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-Regular-B22Nviop.woff2         \x1B[39m\x1B[1m\x1B[2m   26.27 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Typewriter-Regular-D3Ib7_Hf.ttf     \x1B[39m\x1B[1m\x1B[2m   27.56 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_AMS-Regular-BQhdFMY1.woff2          \x1B[39m\x1B[1m\x1B[2m   28.08 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-Bold-Jm3AIy58.woff             \x1B[39m\x1B[1m\x1B[2m   29.91 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-Regular-Dr94JaBh.woff          \x1B[39m\x1B[1m\x1B[2m   30.77 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Math-BoldItalic-B3XSjfu4.ttf        \x1B[39m\x1B[1m\x1B[2m   31.20 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Math-Italic-flOr_0UB.ttf            \x1B[39m\x1B[1m\x1B[2m   31.31 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-BoldItalic-DzxPMmG6.ttf        \x1B[39m\x1B[1m\x1B[2m   32.97 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_AMS-Regular-DMm9YOAa.woff           \x1B[39m\x1B[1m\x1B[2m   33.52 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-Italic-3WenGoN9.ttf            \x1B[39m\x1B[1m\x1B[2m   33.58 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-Bold-waoOVXN0.ttf              \x1B[39m\x1B[1m\x1B[2m   51.34 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_Main-Regular-ypZvNtVU.ttf           \x1B[39m\x1B[1m\x1B[2m   53.58 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mFullDiskAccess-B5uxDzHu.png               \x1B[39m\x1B[1m\x1B[2m   56.45 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[32mKaTeX_AMS-Regular-DRggAlZN.ttf            \x1B[39m\x1B[1m\x1B[2m   63.63 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[35mfullscreen-overlay-BilsSMWy.css           \x1B[39m\x1B[1m\x1B[2m   28.45 kB\x1B[22m\x1B[1m\x1B[22m\n' +
    '\x1B[2m../../out/renderer/\x1B[22m\x1B[2massets/\x1B[22m\x1B[36m__vite-browser-external-BjGS5_Dj.js       \x1B[39m\x1B[1m\x1B[2m    0.22 kB\x1B[22m\x1B[1m\x1B[22m\x1B[2m │ map: '... 5033 more characters,
  stderr: '\x1B[1m\x1B[33m[plugin:vite:resolve]\x1B[39m\x1B[22m \x1B[33m[plugin vite:resolve] Module "crypto" has been externalized for browser compatibility, imported by "/private/var/folders/0g/hj_q_pzx65bbjnslxz9n0src0000gn/T/highlight-electron-temp/standalone/src/shared/ipc/ProcessWideEvents.ts". See https://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.\x1B[39m\n' +
    '\x1B[1m\x1B[33m[plugin:vite:resolve]\x1B[39m\x1B[22m \x1B[33m[plugin vite:resolve] Module "util" has been externalized for browser compatibility, imported by "/private/var/folders/0g/hj_q_pzx65bbjnslxz9n0src0000gn/T/highlight-electron-temp/standalone/node_modules/handlebars-utils/index.js". See https://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.\x1B[39m\n' +
    "node_modules/framer-motion/dist/es/components/AnimatePresence/index.mjs (1:0): Error when using sourcemap for reporting an error: Can't resolve original location of error.\n" +
    "node_modules/framer-motion/dist/es/motion/index.mjs (1:0): Error when using sourcemap for reporting an error: Can't resolve original location of error.\n" +
    '\x1B[1m\x1B[33m[plugin:vite:resolve]\x1B[39m\x1B[22m \x1B[33m[plugin vite:resolve] Module "stream" has been externalized for browser compatibility, imported by "/private/var/folders/0g/hj_q_pzx65bbjnslxz9n0src0000gn/T/highlight-electron-temp/standalone/node_modules/handlebars-async-helpers/helpers/each.js". See https://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.\x1B[39m\n' +
    '\x1B[1m\x1B[33m[plugin:vite:resolve]\x1B[39m\x1B[22m \x1B[33m[plugin vite:resolve] Module "crypto" has been externalized for browser compatibility, imported by "/private/var/folders/0g/hj_q_pzx65bbjnslxz9n0src0000gn/T/highlight-electron-temp/standalone/src/main/utils/crypto/JsonCrypto.ts". See https://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.\x1B[39m\n' +
    '\x1B[1m\x1B[33m[plugin:vite:resolve]\x1B[39m\x1B[22m \x1B[33m[plugin vite:resolve] Module "fs" has been externalized for browser compatibility, imported by "/private/var/folders/0g/hj_q_pzx65bbjnslxz9n0src0000gn/T/highlight-electron-temp/standalone/src/shared/utils/StringUtils.ts". See https://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.\x1B[39m\n' +
    'node_modules/mammoth/node_modules/bluebird/js/release/util.js (201:9): Use of eval in "node_modules/mammoth/node_modules/bluebird/js/release/util.js" is strongly discouraged as it poses security risks and may cause issues with minification.\n'
}

Hey @Galkon! Sorry to hear it. So, that wasn't disk originally. 😞
Then we will need more information for investigation. Can you provide more complete logs? Probably further we will need an example of a project where instability of this kind is observed or at least more recognisable steps of reproduction for localisation of the problem. If suddenly you can find in the history of launches starting from which version of the image this problem began, that would also be very useful.

@erik-bershel looks like some of our failures on one workflow might have been related to our code but one of our workflows (an e2e test workflow) still is not working with macos-14(latest)-large. I still think this might be a disk issue, though it seems like @Galkon's issue is not that. Happy to open a new ticket to investigate further too but as one final check, I'm kicking off that workflow with macos-13-large. Happy to hop on a call/grant support access to debug further or share any needed logs
Based on what you shared it sounds like perhaps the visionOS stuff was included in all available macos images but was only removed from macos14 so not sure if it will work, but I know a past commit run with macos-latest-large on june 19th succeeded (unfortunately logs are gone so I don't know which OS version etc).
On a known good commit, we added some debug info too, before and after snapshots of df are below (regenerating in human readable, will edit in a moment). Based on this, the device has a lot of free space so it's not the OS killing it, but perhaps the "14GB" limit in the host needs to be updated for when it's killed based on tools that have been added or removed over the past few months?
.... regenerating df -ahY ....

Let me know what other info I can provide here

Not sure if that's the proper way to put this, but on macOS 14 Arm64 running source ~/.bashrc overrides the used Node.js version that is set in prior steps via actions/setup-node@v3.
Consider the following job:
jobs:
  test:
    runs-on: macos-latest # macOS 14 Arm64 as of now
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Setup Node.js 22
        uses: actions/setup-node@v3
        with:
          node-version: 22
          cache: "yarn"

     - name: This is where things happen
       run: |
         node --version # 22
         source ~/.bashrc
         node --version # 20 !!!

@Galkon , We believe the latest version of the macos-14-arm64 image you are not facing any issues. If you are still encountering the mentioned issue, please share the workflow code along with the exact error message you are receiving.

@Galkon , We believe the latest version of the macos-14-arm64 image you are not facing any issues. If you are still encountering the mentioned issue, please share the workflow code along with the exact error message you are receiving.

Hey @sureshe456, we moved to our own self hosted runner last week due to builds failing 5-6 times in a row for the same chunking issue. If we try GitHub hosted runners again I'll let you know.

Hi @Galkon  There is no action item pending from our end since your using self hosted runner and we are going to close the issue. We will happily help to your issue by creating new issue along with workflow code whenever you are facing the same issue by using Github hosted runners.


[docs] Best practices

There should be an article titled "Best Practices" under "Runtime Development", containing sub-sections on:

Storage migrations, see: https://github.com/paritytech/substrate/pull/9837#pullrequestreview-761159168
Benchmarking, see: https://substrate.dev/docs/en/knowledgebase/runtime/benchmarking#best-practice-and-common-patterns

Perhaps this should be a new section of pages? There are many topics we can go into here that don't fit the model of HTGs:

parachain config, testing, deployment
devops
unit&integration testing
XCM config & implementation
... I am sure there are more too


update Tor bridge

5bfc219d8b298253b1dba911c724eafa88aca1a1, because this was not tested. I might test it later  and then we could add it back -> remove it it the meantime
Tor browser steps should be sufficient

@kiminuo thanks, applied the suggestions

all feedback applied


Force ping to use a specific address.

This helps when there are multiple networks available on the device running
tuya-convert, as it will force the pings to go via the interface that the
device will convert to, not the default interface.

My setup is to use a Raspberry Pi Zero as a USB gadget, so I can ssh to it over the USB cable connected to my machine. It then runs the tuya-convert stuff, but retains the connection to my local machine.
However, unless I force it to ping on the correct address, it uses the default network interface (which is not the WiFi connection), and never sees the Tuya device connect.

LGTM, thanks!


Add object tracking feature to detections

In this pull request, objects have their own ID next to their names.
I match detections based on the IOU of current and older bounding boxes (if >0.25).
If an object is not present for more than 2 seconds, it is considered gone for good (if <2.0).

And this change, adds the "DOA" tracking as well, correct?

Corrent. It replaces the IOU method with DOA


Missing Transparency handle

If i have an transparent skin, minecraft renders it as black.
Visage renders it as transparent. (Skin: EinCommandBlock)

Ugh. I don't even know how Minecraft does this, and I had a hack to try to mitigate this; guess it doesn't work.

Nevermind, apparently this isn't fixed. I was told what I did would work, it doesn't. -.-


onBoundsChange is called on every visibleTime[Start|End]

Describe the bug
onBoundsChange is called on every visibleTime[Start|End] change and not only when it should.
The use of react-redux might be the reason, but I'm not sure why this happens.
To Reproduce
https://codesandbox.io/s/react-calendar-timeline-bug-timelines-linked-with-redux-u2mkb
Expected behavior
onBoundsChange is supposed to be called when "when the bounds in the calendar's canvas change" (as written in README)
Screenshots

Library Version
0.26.4
Desktop:

OS: Linux
Browser: Firefox
Version 69.0

@hckr  I am not quite sure about this but I think onBoundsChange only applies when you use defaultStartTime and defaultEndTime

Do you mean that onBoundsChange shouldn't be used, when manually changing visibleTimeStart?

@hckr I think so but not quite sure. could you investigate it, please?

I don't understand what do you mean. How should I know if it should work that way or not? I'm not the author of the API. From my point of view, it shouldn't, as it might suggest the canvas is recreated on each scroll which probably is a performance issue. If it isn't recreated, then this event shouldn't fire, as canvas bounds don't change. And they shouldn't change on every scroll, that's why the lib uses a margin on left and right side of the visible area, right?

@hckr me neither I didn't write the API for the boundaries change so this needs to be a collaboration effort from both of us. I agree. This would cause huge performance issues if you are using vistableTime start/end.
The state management to achieve this would be a nightmare I would guess since here we are mixing controlled with uncontolled principles.
We scroll the calendar via scrollLeft property for the headers and the calendar you can read more about it here

So having had the same problem, I probably know the cause of this.
The onBoundsChange event will always fire when items or groups changed. Since your second connected timeline component does not have any items/groups props, a new instance of items and groups will be created whenever the store updates (visible time changes).
Even if your items/groups have the same values as before, the timeline will think they have changed as it's a new instance:
Relevant code.
This returns false: [{id: 1}] == [{id: 1}]
So to solve your problem: Make sure that items and groups are not initialized every time your component rerenders. Move them to state or store.

I don't understand. Items and groups never change, they are created only once in my example (App.jsx):
const { items, groups } = generateFakeData(3, 300);

const App = () => (
  <Provider store={store}>
    <ConnectedTimeline items={items} groups={groups} />
    <ConnectedTimeline />
  </Provider>
);

export default App;

Oh, ok. This is the root cause:

Since your second connected timeline component does not have any items/groups props, a new instance of items and groups will be created whenever the store updates

@meengit thanks for the help


Button "/" considered as "."

I'm not sure is it bug with Atom, but I have this issue since i changed OS to ArchLinux and installed the Atom.
So problem is when I push "Ctrl+/" it considers this as "Ctrl-.". I thought if I'll press "Ctrl+." it will be consider this as "Ctrl+/" but no!
I think it probably something went wrong with my keyboard layout.
Can someone guide me to the right point?

What is the language of your keyboard?
Did you change layouts while Atom was running?
What version of Atom are you using? atom --version

Languages: ru, us, ua
Nope. I didn't changed layouts
Atom 1.12.5(just updated it)
Sooo... When i updated Atom problem gone by itself.
@Ben3eeE , thanks for your help :) Actually without your comment I doubt that I would had tried to update Atom


Ensure that TOTP failures are counted as login failures

A user failing to provide the correct TOTP code more than ten consecutive times will have their account locked, forcing an email reset or time based reset.

coverage: 86.623% (+0.2%) from 86.473%
when pulling 11f00ab5b190ee765c426bc1d889a50a55be28cc on bug/track-mfa-failure
into 633e6e024993fe7f7363f75de074a038cdbafd1f on main.


.netrc authentification does not quote backslash character in password

DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

[X] I understand that I will be blocked if I intentionally remove or skip any mandatory* field

Checklist

[X] I'm reporting a bug unrelated to a specific site
[X] I've verified that I'm running yt-dlp version 2023.07.06 (update instructions) or later (specify commit)
[X] I've checked that all provided URLs are playable in a browser with the same IP and same login details
[X] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[X] I've searched known issues and the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue

Provide a description that is worded well enough to be understood
When using .netrc authentication, if you have a password that contains a backslash character \, it will be treated as an escape character for the next character instead of the backslash literal.
Say for example, your password was a\b and the content of your .netrc file was
machine watchnebula login<EMAIL_ADDRESS>password a\b

yt-dlp would then interpret the password as ab as b escaped just turns into b again. The same does not occur when using --username authentication. If you type a\b in the password prompt, yt-dlp interprets the backslash character as a literal backslash and the entire password as a\b.
I believe this is not intentional behavior since:

Your readme section Authentication with netrc does not mention the need to manually escape backslashes in passwords
Neither does the website about .netrc files you link to in the readme
I couldn't find any information on the internet about the need to manually escape backslashes in passwords in .netrc files.

In the Complete Verbose Output section of this issue, I have slightly modified the code in order to better demonstrate the issue. I have added a print(password) statement to the _get_login_info function in yt-dlp/yt_dlp/extractor/common.py just before https://github.com/yt-dlp/yt-dlp/blob/9b16762f48914de9ac914601769c76668e433325/yt_dlp/extractor/common.py#L1347
so we can see the difference in interpreting the password when running the verbose example with --netrc and with --username. See the line below yt-dlp is up to date<EMAIL_ADDRESS>in the respective verbose outputs.
In my example I use the nebula extractor since this is where I first noticed the issue, however from what I can tell the issue seems to be unrelated to that specific extractor but rather be a core issue.
In order to answer the questions of "How it could be fixed", I would suggest escaping backslashes in .netrc passwords so that backslash literals are still interpreted as backslash literals. In case I am wrong with my assessment and that is actually the intended behavior I would instead appreciate if the need to manually escape backslashes in passwords in netrc authentication was mentioned in the Authentication with netrc section in the readme.
Provide verbose output that clearly demonstrates the problem

[X] Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
[ ] If using API, add 'verbose': True to YoutubeDL params instead
[X] Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output
# using .netrc authentication
~ yt-dlp -vU https://nebula.tv/videos/jetlag-ep-4-we-played-a-96hour-game-of-capture-the-flag-across-japan --netrc
[debug] Command-line config: ['-vU', 'https://nebula.tv/videos/jetlag-ep-4-we-played-a-96hour-game-of-capture-the-flag-across-japan', '--netrc']
[debug] User config "/home/dasug/.yt-dlp/config": []
[debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version<EMAIL_ADDRESS>[b532a3481]
[debug] Python 3.11.3 (CPython x86_64 64bit) - Linux-6.4.3-zen1-2-zen-x86_64-with-glibc2.37 (OpenSSL 3.1.1 30 May 2023, glibc 2.37)
[debug] exe versions: ffmpeg 6.0 (setts), ffprobe 6.0, rtmpdump 2.4
[debug] Optional libraries: Cryptodome-3.12.0, brotlicffi-<IP_ADDRESS>, certifi-2023.05.07, mutagen-1.46.0, secretstorage-3.3.3, sqlite3-2.6.0, websockets-10.4
[debug] Proxy map: {}
[debug] Loaded 1855 extractors
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
Available version<EMAIL_ADDRESS>Current version<EMAIL_ADDRESS>yt-dlp is up to date<EMAIL_ADDRESS>ab
[Nebula] Logging in to Nebula with supplied credentials
WARNING: [Nebula] Authentication failed or rejected: HTTP Error 400: Bad Request
ERROR: [Nebula] jetlag-ep-4-we-played-a-96hour-game-of-capture-the-flag-across-japan: This video is only available for registered users. Use --username and --password, --netrc-cmd, or --netrc (watchnebula) to provide account credentials
  File "/usr/lib/python3.11/site-packages/yt_dlp/extractor/common.py", line 707, in extract
    self.initialize()
  File "/usr/lib/python3.11/site-packages/yt_dlp/extractor/common.py", line 613, in initialize
    self._perform_login(username, password)
  File "/usr/lib/python3.11/site-packages/yt_dlp/extractor/nebula.py", line 109, in _perform_login
    self._nebula_api_token = self._perform_nebula_auth(username, password)
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/yt_dlp/extractor/nebula.py", line 33, in _perform_nebula_auth
    self.raise_login_required(method='password')
  File "/usr/lib/python3.11/site-packages/yt_dlp/extractor/common.py", line 1170, in raise_login_required
    raise ExtractorError(msg, expected=True)

# using --username authentication
~ yt-dlp -vU https://nebula.tv/videos/jetlag-ep-4-we-played-a-96hour-game-of-capture-the-flag-across-japan<EMAIL_ADDRESS>[debug] Command-line config: ['-vU', 'https://nebula.tv/videos/jetlag-ep-4-we-played-a-96hour-game-of-capture-the-flag-across-japan', '--username=PRIVATE']
[debug] User config "/home/dasug/.yt-dlp/config": []
Type account password and press [Return]:
[debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version<EMAIL_ADDRESS>[b532a3481]
[debug] Python 3.11.3 (CPython x86_64 64bit) - Linux-6.4.3-zen1-2-zen-x86_64-with-glibc2.37 (OpenSSL 3.1.1 30 May 2023, glibc 2.37)
[debug] exe versions: ffmpeg 6.0 (setts), ffprobe 6.0, rtmpdump 2.4
[debug] Optional libraries: Cryptodome-3.12.0, brotlicffi-<IP_ADDRESS>, certifi-2023.05.07, mutagen-1.46.0, secretstorage-3.3.3, sqlite3-2.6.0, websockets-10.4
[debug] Proxy map: {}
[debug] Loaded 1855 extractors
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
Available version<EMAIL_ADDRESS>Current version<EMAIL_ADDRESS>yt-dlp is up to date<EMAIL_ADDRESS>a\b
[Nebula] Logging in to Nebula with supplied credentials
[Nebula] Authorizing to Nebula
[Nebula] Extracting URL: https://nebula.tv/videos/jetlag-ep-4-we-played-a-96hour-game-of-capture-the-flag-across-japan
[Nebula] jetlag-ep-4-we-played-a-96hour-game-of-capture-the-flag-across-japan: Fetching video meta data
^C
ERROR: Interrupted by user

We use Python's netrc parsing as-is. This behavior appears to be a consequence of https://github.com/python/cpython/pull/26330. You may wish to redirect the report to Python devs if this is not to spec.

Actually, appears the bug is already reported. https://github.com/python/cpython/issues/99080. If this gets merged in a future python version, we could add a workaround for 3.11. But if instead, Python devs deem this the expected behavior, I do not want to go against it.

I see, I didn't catch on to the fact that this is an issue in python itself, sorry about that!
Yeah, in this case it probably makes sense to for now wait and see how python handles that issue. Thanks for looking into this!


Allow resizing pop-up player

See NewPipe and VLC for reference. NewPipe handles PiP resizing better, since the picture gets resized as you drag it, while the VLC pop-up window gets resized only after you let it go.

Just Player uses native Android PiP feature which already allows resizing (since Android 11).

Oh, I see. Though NewPipe uses ExoPlayer as well and allows resizing on Android < 11.

Oh, I see. Though NewPipe uses ExoPlayer as well and allows resizing on Android < 11.

NewPipe uses an overlay (pop-up player) and requires the permission "Draw over other apps" for it to work.

NewPipe uses an overlay (pop-up player) and requires the permission "Draw over other apps" for it to work.

@DarremMolko I thought this was the same thing, turns out it isn't. Thanks for explaining.
@moneytoo feel free to close this if you don't intend to overhaul the pop-up player in sake of people who use older Android versions.


fix: update docker-compopse env vars

Benchmark results
No metrics with a significant change found.

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Proof generation
Each column represents the number of threads used in proof generation.

Metric
1 threads
4 threads
16 threads
32 threads
64 threads

proof_construction_time_sha256_ms
5,709
1,538
706
743 (+2%)
774

proof_construction_time_sha256_30_ms
11,709
3,129
1,400
1,444 (+1%)
1,449

proof_construction_time_sha256_100_ms
44,559
11,991 (-1%)
5,665
5,593 (+1%)
5,489

proof_construction_time_poseidon_hash_ms
79.0
34.0
34.0
57.0 (-2%)
87.0 (-1%)

proof_construction_time_poseidon_hash_30_ms
1,514
420 (+1%)
201 (+1%)
228 (+4%)
271 (+2%)

proof_construction_time_poseidon_hash_100_ms
5,729
1,573
724
781
789 (-1%)

L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
4 txs
8 txs
16 txs

l1_rollup_calldata_size_in_bytes
1,412
1,412
1,412

l1_rollup_calldata_gas
9,476
9,450
9,464

l1_rollup_execution_gas
610,297
610,271
610,285

l2_block_processing_time_in_ms
702
1,291
2,454

l2_block_building_time_in_ms
22,148 (-1%)
45,856
86,442 (-1%)

l2_block_rollup_simulation_time_in_ms
22,043 (-1%)
45,501
86,049 (-1%)

l2_block_public_tx_process_time_in_ms
18,937 (-1%)
42,100
82,748 (-1%)

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 8 txs.

Metric
3 blocks
5 blocks

node_history_sync_time_in_ms
5,928
8,494 (-1%)

node_database_size_in_bytes
9,486,416
12,697,680

pxe_database_size_in_bytes
9,242
15,127

Circuits stats
Stats on running time and I/O sizes collected for every kernel circuit run across all benchmarks.

Metric
1 leaves
16 leaves
64 leaves
128 leaves
256 leaves
512 leaves
1024 leaves
32 leaves

batch_insert_into_append_only_tree_16_depth_ms
10.4
16.9 (+1%)
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_count
16.7
31.8
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_ms
0.604
0.517
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_32_depth_ms
N/A
N/A
48.6
76.3 (+1%)
135 (+2%)
248
474
N/A

batch_insert_into_append_only_tree_32_depth_hash_count
N/A
N/A
95.9
159
288
543
1,055
N/A

batch_insert_into_append_only_tree_32_depth_hash_ms
N/A
N/A
0.495
0.470 (+1%)
0.461 (+1%)
0.450 (+1%)
0.443
N/A

batch_insert_into_indexed_tree_20_depth_ms
N/A
N/A
59.1
113 (+1%)
185 (+1%)
356
699 (+1%)
N/A

batch_insert_into_indexed_tree_20_depth_hash_count
N/A
N/A
108
208
355
691
1,363
N/A

batch_insert_into_indexed_tree_20_depth_hash_ms
N/A
N/A
0.503
0.508 (+1%)
0.490 (+1%)
0.483
0.479
N/A

batch_insert_into_indexed_tree_40_depth_ms
N/A
N/A
N/A
N/A
N/A
N/A
N/A
59.8

batch_insert_into_indexed_tree_40_depth_hash_count
N/A
N/A
N/A
N/A
N/A
N/A
N/A
103

batch_insert_into_indexed_tree_40_depth_hash_ms
N/A
N/A
N/A
N/A
N/A
N/A
N/A
0.550

Miscellaneous
Transaction sizes based on how many contract classes are registered in the tx.

Metric
0 registered classes
1 registered classes

tx_size_in_bytes
79,470
665,267

Transaction size based on fee payment method
| Metric |  |
| - |  |


css: Remove Bootsrap CSS reset for hr elements

This PR is part of the efforts to remove Bootstrap CSS resets. The scope of the change here is the removal of the Bootstrap CSS resets for
 elements.
@timabbott and I started working on this in a pair programming session. Initially, we were going to target the
 elements with selectors matching existing classes used by parent containers (e.g. .popover hr). However, it turned out if we were going to do so, we'd have to duplicate the styles in at least 3 rule sets.
So the idea came up to create a separator component, i.e. a template that contains only the  styled
 element and including this template everywhere where we have an
 element. But then we wouldn't be able to reuse this component across client-side (Handlbars) and server-side (jinja2) templates. Let alone that the boilerplate to include the template would be more verbose than typing out
 which is the solution we ended up with.
For reference, the changes to the .html and .hbs files have been performed with following command:
sed -Ei 's/(<\s*hr)/\1 class="separator"/' $(git grep '<\s*hr\b' | cut -d: -f1 | sort -u | grep -E '(html|hbs)$')

I tested the following components verifying that there are no visual changes:

three dot menu in streams list
three dot menu in messages
logged out jobs page

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[x] Highlights technical choices and bugs encountered.
[x] Calls out remaining decisions and concerns.
[x] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[ ] Responsiveness and internationalization. (n/a)
[ ] Strings and tooltips. (n/a)
[x] End-to-end functionality of buttons, interactions and flows.
[x] Corner cases, error conditions, and easily imagined bugs.

Thanks for the PR @snoack! Did you come up with a strategy for determining whether adding the rule (hr.separator has a higher CSS precedence than hr) might accidentally override existing CSS rules for hr elements that were intended to override Bootstrap? One thing I notice in git grep hr static/styles/ is that static/styles/dark_theme.css has some styles for separators; we should make sure we're not getting a priority inversion for these elements in the dark theme.

According to the spec, the specificity of hr.separator is (0,1,1) while the specificity of hr is (0,0,1). Therefore a rule set for the selector hr.separator takes precedence over rule sets for the selector hr. As for the dark theme, the relevant selector there is :root.dark-theme hr which has a specificity of (0,2,1) and therefore takes precedence over the rules defined for hr.separator. In fact, I was using the dark theme when I initially tested these changes.


Drop databricks-sql-connector 1.0.

Description
Drops databricks-sql-connector 1.0 that will be deprecated soon.

Thanks! merging.


ARROW-8684: [Python] Do not call tobytes inside atexit extension type teardown function

It seems that Cython calling out to some pure Python code (here pyarrow.compat.tobytes) inside the atexit handler hits an esoteric bug on Python >= 3.7.5 on macOS. These code changes fix the problem for me. I'll try to create a minimal reproducer for the benefit of the Cython issue tracker since this seems to be a Cython bug

I spent maybe 20 minutes fruitlessly trying to create a minimal reproducer of the original issue. I don't like fixing a bug without understanding it, but if someone else is able to figure out the problem that would be great

@pitrou since this is reproducible on macOS, if it were possible to produce a debug build of CPython and build pyarrow against it (I tried, but since wheels can't be installed a bunch of things would need to be built from source) then we might be able to determine how exactly this bug is triggered. I'm concerned that there might be some "deterministic non-determinism" going on here and this bug could arise again in the future

closing per proper fix #7160


Vendor extensions: Add Nuclei vendor extensions

This patch defines the Nuclei Instruction prefix xl, abbreviation of XinLai(Chinese pronunciation of Nuclei 芯来科技).

Just wait few more days to see if any other comment or concern.


Show default language tabs when language selection is not available

This is a followup from #57 - when a tabbed language component does not list the currently selected language tab the tab component will appear empty. This is confusing behavior and we should fix it (whether by falling back to a default tab or showing a 'fake' tab noting that the currently selected language is not available for the code block depends on further UX-considerations).

I did some spelunking and realized that Docusaurus saves the selected value in localStorage under the key docusaurus.tab.reactr-language (in this case), which explains why I was having problems reproducing this earlier.

I just pushed a fix for this in #105
At this week's docs meeting there was discussion about displaying all tabs even when they are not present. Technically this is perfectly feasible (in fact, we explicitly filter out the languages not used as we display the component). I believe from a UX perspective showing 6 languages that do not have any content is not ideal (particularly on smaller screen sizes, think phones and tablets), but I can be convinced, @LauraLangdon @ramonh feel free to open another issue for that.
Another thing mentioned was having a "phantom" tab show up whenever the currently chosen language has no tabs present, I actually kinda like this idea, and it feels like a good tradeoff in terms of UX as well, again, feel free to file a follow-up issue for that (I need to think a bit more about this, but I may do so myself).


[Request-for-external] codeunit 99000855 "Planning-Get Parameters"

Hi, I was wondering if it would be possible to change the procedure AssignToArray in codeunit 99000855 "Planning-Get Parameters" from local to external.
My team and I use this procedure a lot in our code, and changing it to external would be a huge help.
Thanks

This functions is not specific to Planning and can be located at any place. If you use this often, just add this procedure to you shared code library. I don't like to expose it as this implementation can be changed to more up-to-date design.


Revert "Remove redundant EXECUTABLE_NAME overrides in PIF"

Reverts swiftlang/swift-package-manager#7906, which is causing failures in toolchain builds.

@swift-ci please test

@swift-ci please test Linux platform

@swift-ci please test

Previous runs will all fail because of the foundation issue. That's fixed now, re-running.


Add example for redirecting back to the "referer" page

I'm trying to make the plugin redirect to the page from which the user navigated to /auth/github. I can't get the ''Referer" header, since I can't access the event object outside of onSuccess. What is the recommended method and can we add it to the documentation?
// Code from README.md example
export default oauthGitHubEventHandler({
  config: {
    emailRequired: true
  },
  async onSuccess(event, { user, tokens }) {
    await setUserSession(event, {
      user: {
        githubId: user.id
      }
    })
    return sendRedirect(event, '/') // Redirect back to the referrer
  },
  onError(event, error) {
    console.error('GitHub OAuth error:', error)
    return sendRedirect(event, '/') // Redirect back to the referrer
  },
})

Hey,
This is called intended redirect (I'm working on a module) but you have to store the current path in a cookie when your Nuxt Middleware detect that the user should be logged in.
Then, in the onSuccess, you just have to get the cooke value and to redirect to it or the default value if it does not exists.

In your Nuxt application (./app), you should have a middleware named auth or similar that restrict access to some parts of your application. Within the middleware, you use the composable useCookie, https://nuxt.com/docs/api/composables/use-cookie to write a cookie with the route that the user want to access using from.
Then, in the Nitro part (server), you can read this cookie and redirect the Nuxt app to this page.

What about the case when a user just clicks a login button in the toolbar from some of the pages (which is a direct link to /auth/github)? I would need to set a cookie on every page the user visits. I'm talking about the scenario when the user logs in willingly, without being forced into a login page.

You can intercept the click, set the cookie and then redirect using navigateTo.


Glide flag not functioning properly

Hi,
I've been using the plugin for quite some time and it's always been fine. Recently the glide flag has stopped functioning properly. When someone tries to glide in a region it will effect flight, but they can spam spacebar and still fly, it also allows them to jump 2 blocks high which ruins a few maps I have.
Is this something known or is there another explanation or fix I could try?
Thanks,
JK

This is a vanilla thing. This is similar to how flying/double jumps also works.
When you have elytra the client knows it can glide. So the client can start to glide at any moment it thinks its possible (the player is in the air) and has no knowledge of regions. So when you start to glide it thinks its fine because in vanilla there's no regions preventing you to glide so it tells the server "Hey, I'm gliding!".
Because of latency this message takes some time to arrive to the server and as soon as it does the server checks that hey, they are in a region that says gliding is not allowed! And sends the client message "Hey, stop gliding!" and this message also takes some time to arrive at the client.
When the client receives the message that it needs to stop gliding it does so. But nothing is stopping him to start gliding again so the process goes on.


ranking exposure: add sqre-expl als erklärungs audio

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

see #167


'KeyError' in main branch

Describe the bug
Bug in the version currently in 'main'. very similar KeyError, but I think it occurs when the player left the server after "endTick" but before "endOfficialTick"
Version of awpy currently in PyPi does not cause this problem
Include Information to Reproduce
Demo file: https://drive.google.com/file/d/1twVayyVeYNu6QoUYEZ0HQNxWhx3VIE09
Code
from awpy.parser import DemoParser
from awpy.analytics.stats import player_stats

parser = DemoParser(
    demofile='C:/1-a8917f91-390e-4479-807d-a672e9155be1-1-1.dem',
    demo_id='1-a8917f91-390e-4479-807d-a672e9155be1-1-1'
)

parse_data = parser.parse()
player_stats_json = player_stats(parse_data["gameRounds"])

---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)
Cell In[3], line 10
      4 parser = DemoParser(
      5     demofile='C:/1-a8917f91-390e-4479-807d-a672e9155be1-1-1.dem',
      6     demo_id='1-a8917f91-390e-4479-807d-a672e9155be1-1-1'
      7 )
      9 parse_data = parser.parse()
---> 10 player_stats_json = player_stats(parse_data["gameRounds"])

File ~\AppData\Local\pypoetry\Cache\virtualenvs\bcl-rating-api-4C7xlnMJ-py3.11\Lib\site-packages\awpy\analytics\stats.py:655, in player_stats(game_rounds, return_type, selected_side)
    651 for game_round in game_rounds:
    652     # Add players
    653     round_statistics = initialize_round(game_round, player_statistics, active_sides)
--> 655     _handle_kills(game_round, player_statistics, round_statistics)
    656     _handle_damages(game_round, player_statistics, round_statistics)
    657     _handle_weapon_fires(game_round, player_statistics, round_statistics)

File ~\AppData\Local\pypoetry\Cache\virtualenvs\bcl-rating-api-4C7xlnMJ-py3.11\Lib\site-packages\awpy\analytics\stats.py:467, in _handle_kills(game_round, player_statistics, round_statistics)
    463     round_statistics["players_killed"][victim_side].add(victim_key)
    464 _handle_pure_killer_stats(
    465     killer_key, player_statistics, round_statistics, kill_action=k
    466 )
--> 467 _handle_pure_victim_stats(
    468     victim_key,
    469     player_statistics,
    470     round_statistics,
    471     kill_action=k,
    472     game_round=game_round,
    473 )
    474 _handle_trade_stats(
    475     killer_key, player_statistics, round_statistics, kill_action=k
    476 )
    477 _handle_assists(
    478     assister_key,
    479     flashthrower_key,
   (...)
    482     kill_action=k,
    483 )

File ~\AppData\Local\pypoetry\Cache\virtualenvs\bcl-rating-api-4C7xlnMJ-py3.11\Lib\site-packages\awpy\analytics\stats.py:372, in _handle_pure_victim_stats(victim_key, player_statistics, round_statistics, kill_action, game_round)
    370 if kill_action["isSuicide"]:
    371     player_statistics[victim_key]["suicides"] += 1
--> 372 _handle_clutching(kill_action, game_round, round_statistics, player_statistics)

File ~\AppData\Local\pypoetry\Cache\virtualenvs\bcl-rating-api-4C7xlnMJ-py3.11\Lib\site-packages\awpy\analytics\stats.py:350, in _handle_clutching(kill_action, game_round, round_statistics, player_statistics)
    348 if not proper_player_number(enemies_alive) or enemies_alive == 0:
    349     return
--> 350 player_statistics[clutcher_key][
    351     "attempts1v" + int_to_string_n_players(enemies_alive)
    352 ] += 1
    353 if game_round["winningSide"] == kill_action["victimSide"]:
    354     player_statistics[clutcher_key][
    355         "success1v" + int_to_string_n_players(enemies_alive)
    356     ] += 1

KeyError: ''

The issue here is the player leaving in warmup (which counts as a death) and then rejoining. When 3 of his teammates die during the round the clutching logic is triggered because (5-1) player have died in his team. When he dies again the logic is triggered again. But since his teammate is already clutching he wont be selected again as a clutcher and instead an empty string is returned.
This triggers the KeyError.
I have to think how to fix this properly. It worked in 1.2.3 because the assignment of the clutching player worked slightly differently. However the underlying problem that a reconnecting player triggers the clutching logic already at 2 players alive was already present and could lead to false entries into the clutching statistic.

Clutching logic in case anyone wants to have a pass at improving/cleaning this.
https://github.com/pnxenopoulos/awpy/blob/main/awpy/analytics/stats.py#L318

The KeyError should be adressed here: https://github.com/pnxenopoulos/awpy/pull/249
Underlying issue still remains.

Closing this for now. Feel free to reopen if the underlying problem causes issues.


Yatin: Watch att688.com

Yatin requests the watch of the watch_keyword att688\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

att688\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

att688\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Rejected by Mast in Charcoal HQ. Reason: 'Sorry, duplicate.'

Rejected by Mast in Charcoal HQ. Reason: 'Sorry, duplicate.'


Allow explicit targeting to psnr/ssim/etc.

Is your feature request related to a problem? Please describe.
As well as targeting size/bpp, it would also be useful to target a specified fidelity type and value.
Describe the solution you'd like
Would like a  --target_((psnr)|(ssim)|...)=X option to help slot in to static (Web site) image generation.
cwebp has an option that works nicely for me right now, see
https://www.earth.org.uk/note-on-site-technicals-51.html#2021-08-12
Describe alternatives you've considered
Writing my own script loop (again) around one of the other --target_XXXs.
Additional context
https://www.earth.org.uk/note-on-site-technicals-51.html#2021-08-12

I mean, you don't really need to target psnr and ssim, since they are not very good metric psycho visually speaking.
Butteraugli distance(-d) already serves the purposes you want while being much more accurate to human perception.

PSNR is not a good metric for image compression. As mentioned by the above comment, you can use the -d parameter, which uses Butteraugli:
 -d maxError, --distance=maxError
    Max. butteraugli distance, lower = higher quality. Range: 0 .. 15.
    0.0 = mathematically lossless. Default for already-lossy input (JPEG/GIF).
    1.0 = visually lossless. Default for other input.
    Recommended range: 0.5 .. 3.0.

P.S. This is how @jonsneyers (co-creator of JPEG XL) describe PSNR (on JPEG XL Discord server):

PSNR correlates with human perception like the weight of a painting in kilograms correlates to its artistic value.
It reflects the amount of paint that went into the painting, but it doesn't care about where what color went. Pretty accurate analogy.

I hear you, but where existing systems have PSNR available and not others, eg on older distros, and they work, then it can be best to continue with what there is.

Uhhh, -d X is literally a JXL command.
If you have CJXL installed, you instantly have it available.
In fact, -d as said before is literally a target-quality mode, similar to "target psnr/ssim", but a lot better.

OK, thanks, good point.
For me that does mean finding or bulding a butteraugli distance tool on older systems for non-JXL inputs, but it may be do-able.

If you build libjxl from sources, it will automatically build the standalone butteraugli_main tool.

OK, sounds promising.

Note that butteraugli_main is built only if -DJPEGXL_ENABLE_DEVTOOLS=YES is passed to CMake (or edited in CMakeCache.txt):
https://github.com/libjxl/libjxl/blob/3f663b602625e7f6595b1a3e7a18a87e618d05e3/tools/CMakeLists.txt#L161-L171
ssimulacra_main implements another metric, namely SSIMULACRA (as you probably guessed), which you might also be interested in.

Incidentally (still learning the tools here) when I try and use --target_size from a .jpg it seems to actually ignore the --target_size in effect:
% cjxl -v -s 9 --target_size=8200 img/RPiServer/RPi-in-box-800w.jpg
JPEG XL encoder v0.5.0 [AVX2,SSE4]
No output file specified.
Encoding will be performed, but the result will be discarded.
Butteraugli distance 4.054 yields  14311 bytes, 0.594 bpp.
Butteraugli distance 7.076 yields  14311 bytes, 0.594 bpp.
Butteraugli distance 12.349 yields  14311 bytes, 0.594 bpp.
Butteraugli distance 16.000 yields  14311 bytes, 0.594 bpp.
Butteraugli distance 16.000 yields  14311 bytes, 0.594 bpp.
Butteraugli distance 16.000 yields  14311 bytes, 0.594 bpp.
Butteraugli distance 16.000 yields  14311 bytes, 0.594 bpp.
Read 800x241 image, 26.9 MP/s
Encoding [Container | JPEG, lossless transcode, tortoise | JPEG reconstruction data], 2 threads.
Compressed to 14311 bytes (0.594 bpp).

If I first convert the source jpg to a png then use otherwise the same argument, all is as I expect:
% convert img/RPiServer/RPi-in-box-800w.jpg ~/tmp/test.png
% cjxl -v -s 9 --target_size 8200 ~/tmp/test.png ~/tmp/test.jxl
JPEG XL encoder v0.5.0 [AVX2,SSE4]
Butteraugli distance 4.054 yields   8159 bytes, 0.339 bpp.
Butteraugli distance 4.034 yields   8172 bytes, 0.339 bpp.
Butteraugli distance 4.020 yields   9046 bytes, 0.375 bpp.
Butteraugli distance 4.435 yields   8356 bytes, 0.347 bpp.
Butteraugli distance 4.519 yields   6949 bytes, 0.288 bpp.
Butteraugli distance 3.830 yields   8514 bytes, 0.353 bpp.
Butteraugli distance 3.976 yields   9063 bytes, 0.376 bpp.
Read 800x241 image, 10.4 MP/s
Encoding [VarDCT, d4.034, tortoise], 2 threads.
Compressed to 8172 bytes (0.339 bpp).

So maybe I'm misunderstanding even more than I thought...

That's a bug of our command line - we should fix it, but in the meantime, you could pass -j to fix the issue.

Thanks!

Thanks!

https://github.com/libjxl/libjxl/pull/442
This should do it...

Since we already have --distance which does encode to a specified perceptual target, I think that is enough.
We could add different metrics to optimize for, but I don't think we want to focus on that, especially since we don't really have a metric available that will work better (psnr/ssim will not). So I'm closing this one for now.

since we don't really have a metric available that will work better

Now that you have such a metric (ssimulacra2), would it make sense reopening and maybe think about adding this as a second option to -d?

I'd vote for that, strongly!
Rgds
Damon


Consider n8n

https://github.com/truecharts/charts/tree/master/charts/stable/n8n

Doesn't look like I have a use for it.


driving over tiled colliders is not smooth

instead of a large collider as floor, having many colliders as floor creates for a bumpy ride

I'm having the exact same issue, trying to find a way to fix it but as of now in Unity 2019.4, it's bugged when going over tiled mesh floor.

I am also facing this same issue while driving on an uneven track, Did anyone find any solution for this?


Backslash in JSON Configuration File

Backslashes are only read by JSONConfigurationLoader if they are escaped in the file by using double backslashes. This is annoying for creating path configurations on any file system using \ as the file separator (most notably Windows)

After looking into the source code, this appears to be a problem with Jackson, can someone please confirm? By the way, I'm using the following versions...

Configurate Core 2.0
Configurate JSON 2.0
Jackson Core 2.5.3
Guice 4.0
Guava 17.0
Animal Sniffer Annotations 1.14

I'm using these dependencies as they are required by Configurate JSON. I'm using the version Configurate was built on at 2.0, so mismatching versions can't be the problem.

Nevermind, Jackson requires you to escape backslashes simply to allow you to define strings containing special characters like ", therefore this is most likely intended.


chore: remove Owlbot yaml

I think we should only remove these two files after we introduce generation_config.yaml to sdk-platform-java.

Merge it after we introducing library generation workflow.