all new builds resulting in internal errors failing - read-only filesystem error

Before opening, please confirm:

[X] I have checked to see if my question is addressed in the FAQ.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

App Id
dg7tx6xd2q14q
AWS Region
us-east-2
Amplify Hosting feature
Build settings
Frontend framework
Next.js
Next.js version
13.5.2
Next.js router
App Router
Describe the bug
Everything is throwing 500s now -
2023-11-07T15:30:57.605-05:00	ln: failed to create symbolic link ‘/tmp/app/amplify-compute-bundle-output/amplify-compute-bundle-output’: Read-only file system

2023-11-07T15:30:57.605-05:00	ln: failed to create symbolic link ‘/tmp/app/node_modules/node_modules’: Read-only file system

2023-11-07T15:30:57.606-05:00	ln: failed to create symbolic link ‘/tmp/app/public/public’: Read-only file system

2023-11-07T15:30:57.607-05:00	ln: failed to create symbolic link ‘/tmp/app/src/src’: Read-only file system

2023-11-07T15:30:57.623-05:00	ln: failed to create symbolic link ‘/tmp/app/.next/types/types’: Read-only file system

2023-11-07T15:30:57.623-05:00	ln: failed to create symbolic link ‘/tmp/app/.next/server/app/app’: Read-only file system

2023-11-07T15:30:57.637-05:00	ln: failed to create symbolic link ‘/tmp/app/.next/server/chunks/chunks’: Read-only file system

2023-11-07T15:30:57.642-05:00	ln: failed to create symbolic link ‘/tmp/app/.next/server/src/src’: Read-only file system

Trying to redeploy a previous version of my app has the same issues, so not related to any code changes on our side
Expected behavior
Shouldn't blow up on every request
Reproduction steps
Our app is completely nonfunctional now
Build Settings
No response
Log output

# Put your logs below this line
2023-11-07T15:30:57.605-05:00	ln: failed to create symbolic link ‘/tmp/app/amplify-compute-bundle-output/amplify-compute-bundle-output’: Read-only file system

2023-11-07T15:30:57.605-05:00	ln: failed to create symbolic link ‘/tmp/app/node_modules/node_modules’: Read-only file system

2023-11-07T15:30:57.606-05:00	ln: failed to create symbolic link ‘/tmp/app/public/public’: Read-only file system

2023-11-07T15:30:57.607-05:00	ln: failed to create symbolic link ‘/tmp/app/src/src’: Read-only file system

2023-11-07T15:30:57.623-05:00	ln: failed to create symbolic link ‘/tmp/app/.next/types/types’: Read-only file system

2023-11-07T15:30:57.623-05:00	ln: failed to create symbolic link ‘/tmp/app/.next/server/app/app’: Read-only file system

2023-11-07T15:30:57.637-05:00	ln: failed to create symbolic link ‘/tmp/app/.next/server/chunks/chunks’: Read-only file system

2023-11-07T15:30:57.642-05:00	ln: failed to create symbolic link ‘/tmp/app/.next/server/src/src’: Read-only file system

Additional information
No response

Hi @scottwmorris 👋 , thanks for raising this and apologies for the inconvenience caused due to this issue.
We are actively investigating into it and will keep you posted with any updates.

@scottwmorris @iamcgn Thank you for your continued patience.
Between 07:37 AM PST and 2:38 PM PST we experienced problems deploying Next.js apps that didn’t include any static asset. The issue has been resolved and the service is operating normally.


docs: Suggest mathematically correct use of sum_over_time

See the docs change itself in the commit.

:thinking: This paragraph is a really compressed, dealing with all the ..._over_time functions in one go. Expanding one of the paragraphs a lot to explain usage implications and best practices seems out of place. Furthermore, your notes aren't even sufficient. If you really wanted to explain "mathematically correct" integration, you also needed to explain the problem with changing sampling intervals, missing samples, and series starting or stopping (see the long winded discussion over in #14440).
We are running into the general problem here that (most of) the documentation on prometheus.io is in fact terse reference documentation, and that we don't have a good place yet for documentation that is more oriented towards explaining usage. We need to address this problem, but sprinkling explanation all over in between the reference documentation will make things even worse.
I think what we have here is actually beautiful because it is so short and it says on the tin exactly what you get. How to use counters vs. already rate'd metrics and how to navigate the pitfalls of the ..._over_time function could be part of the "Best Practices" section or maybe a tutorial in the "Tutorial" section. (Don't ask we what the precise difference is between "Tutorials" and "Guides" … another sign that we really need to properly structure the website.)

Don't ask we what the precise difference is between "Tutorials" and "Guides" … another sign that we really need to properly structure the website.

I think it was originally meant by the people who introduced those sections as differentiated on https://rasa.com/blog/writing-a-technical-tutorial-or-guide-to-support-the-open-source-community/:

What is the difference between a tutorial and a guide?
A tutorial teaches the audience a new idea or concept by showing how to accomplish a goal. Tutorials take you through a technical process step-by-step and tend to get straight to the point.
A guide is usually focused on achieving a particular task and can assume some level of prerequisite knowledge. Like tutorials, they have a clear focus but also include cautionary advice and additional information. Guides may also suggest multiple approaches to accomplishing the task.

Off-topic, of course, for this PR, but still: Even if we have a good definition of the difference, the question is if we should really have separate sections. Including the subtly different https://prometheus.io/docs/guides/go-application/ vs. https://prometheus.io/docs/tutorials/instrumenting_http_server_in_go/ …

To come back to the topic here: I guess that means we could have a guide around the topic "how to use ..._over_time functions" or maybe even specifically "How to use sum_over_time and how to avoid it (by using the underlying counter)". I could also see this as an article in the "Best Practices" section, though.

In any case, such an article would be a way bigger effort than what's proposed in this PR. @samjewell you are more than welcome to write such an article, but no obligations, of course. But I think it makes most sense to close this PR (which doesn't prevent reusing the content here for such an article).

Got it. Thanks for the consideration and feedback.


Changes to swizzled ApiExplorer/SecuritySchemes do not take effect.

Describe the bug
When I swizzle (eject) ApiExplorer/SecuritySchemes, the changes I make to the index.js file do not take effect.
To keep things simple I wanted to expand the Security Schemes section by default. To accomplish this I was changing line 24 to set open to true:
{ className: "openapi-security__details", open: true }

Expected behavior

I would expect that the dropdown here would be expanded when I open the page.

Current behavior
Right now nothing happens when I change this value or anything else on the swizzled component.

Possible solution

Context
Our users don't necessarily know that that AUTHORIZATION: OAUTH can be expanded. Adding an arrow to show that this section could be expanded and closed. The section is a little cluttered for us and we wanted to remove some of the extra properties description and flows. We also wanted to add a custom variable in our spec and read it in and show it in this section as well.

Your Environment

Version used:
Docusaurus Version: 2.4.3
docusaurus-theme-openapi-docs version: 2.0.2
Environment name and version (e.g. Chrome 59, node.js 5.4, python 3.7.3): Chrome Version 124.0.6367.203
Operating System and version (desktop or mobile): MacOS 14.5 (23F79)
Link to your project: https://github.com/sailpoint-oss/developer.sailpoint.com

Hi @tyler-mairose-sp, you'd have to swizzle the entire ApiExplorer component for the override to work. Heads up that you may need to change an import statement for MethodEndpoint from "../../ApiItem/hooks" to "@theme/ApiItem/hooks"

Will update docs coinciding with next stable v2/v3 release

@sserrata That worked. I also had to install the react-live package to get it to work. That issue was coming from ApiExplorer/LiveEditor/index.js
Thank you!


typo in the function's name?

(shouldn't it be _parse_ celeba?)
https://github.com/hrayrhar/nnlib/blob/909cb7abb3996bbbb3de99c3b4d434c6329bc0fa/nnlib/data_utils/base.py#L254

Thanks @keyboardAnt, good catch. Yes the name should be _parse_celeba (though what we have now causes will cause no issues). Please let me know if you want to open a pull request, otherwise I will fix it.

Oh, actually found out that I had fixed it some time ago. The master branch has it corrected. Anyway, thanks for noticing it.


openai prerelease is a breaking change

openai python is pushing a pre-release to test before breaking changes come in January.
Using autogen assistant agent in an environment with openai pre installed gives an error message "openai and diskcache must be installed."

Thanks for reporting this issue. #203 is created for this.


Retarget master as the base branch for docs metadata release

Have a PR submitted to the docs team that allows for non-conflicting commits. We can definitely get rid of smoke-test now.
Docs CI will also need to be updated, but that happens separately from this PR.

The following pipelines have been queued for testing:java - templatejs - templatenet - templatepython - template You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

Double checked that everything is g2g

Going to go through the merge processes now.

The sync is green, but the check didn't properly come back. I'm going to override and merge.

/check-enforcer override


IP Object duck typing is leaky

In noflo-ui we're sending a packet that is an object that contains a data key. That gets converted in NoFlo to an IP object containing only the contents of the data key instead of IP object containing the whole original object.
This is the reason why we get noflo/noflo-ui#600

@bergie is it possible to set IP .type property in noflo-ui as well? Because without that neither duck typing nor brackets can work.

@trustmaster the problem here is that in noflo-ui we send packet objects through the graph, and they suspiciously resemble an IP object even though that is not the intent.
See noflo/noflo-runtime#88

Any ideas at what stage it may be happening? I can't recall any place where .data is used to detect packet type, the actual check is https://github.com/noflo/noflo/blob/master/src/lib/IP.coffee#L13

@trustmaster here is the original outport.send command: https://github.com/noflo/noflo-runtime/blob/2afb74aacb345e6a2dcf55a90b6db44958e781b3/components/ListenNetwork.coffee#L43
As you can see the payload is an object that contains type: 'data'

@bergie thanks, got it. We can try to switch to strict typing then.


CP Section not found

The Plugin.php has the $hasCpSection set to true, but no CP Section exists. I'm getting a 404 on /admin/messagebird.
Does the plugin have a cp section?

Good catch. Probably copied from some other plugin example ;-) will remove it soon

is this going to be fixed soon?

Fixed & released! 🥳


master -> live

Docs Build status updates of commit 6719369:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/create-packages/multiple-target-frameworks-project-file.md
:white_check_mark:Succeeded
View

docs/nuget-org/id-prefix-reservation.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


feat(exports): update exports to pass through carbon components

Summary

@jonguenther pointed out a few components that are available in Carbon but not available through our package

Change List (commits, features, bugs, etc)

update index.js exports

Acceptance Test (how to verify the PR)

run a local build, these should be there
the exports table in the welcome story should be updated to show these as available from our package

:tada: This PR is included in version 2.139.0-next.2 :tada:
The release is available on:

npm package (@next dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


"unknown type" in Buffer.writeValues()

Turns out that Parse() can handle counter metrics, but Buffer.writeValues() can't write them.
panic: unknown type

goroutine 1 [running]:
collectd.org/network.Fuzz(0x7fe8fa833000, 0xf, 0x200000, 0x10)
        /tmp/go-fuzz-build999482993/src/collectd.org/network/fuzz.go:47 +0x339
github.com/dvyukov/go-fuzz/go-fuzz-dep.Main(0x652568)
        /usr/local/google/home/octo/go/src/github.com/dvyukov/go-fuzz/go-fuzz-dep/main.go:47 +0x13d
main.main()
        /tmp/go-fuzz-build999482993/src/go-fuzz-main/main.go:10 +0x2a

Fuzzing FTW!   You can list your fixes at the bottom of this page if you are so inclined: https://github.com/dvyukov/go-fuzz

@ryancox I've added #10 to that list. I didn't add this one because it was an unexpected error, rather than an actual crash – you already took care of the panic() in #6 :-)