Clarify usage or URN for an AsyncAPI spec id

Describe the bug
The documentation of the id property of an AsyncAPI spec currently recommends using a URN as an id (https://www.asyncapi.com/docs/specifications/v2.3.0#A2SIdString).
The RFC of URN states that a URN needs to have a registered namespace in order to be valid:

While other URI schemes may allow resource identifiers to be freely chosen and assigned, such is not the case for URNs.  The syntactical correctness of a name starting with "urn:" is not sufficient to make it a URN.  In order for the name to be a valid URN, the namespace identifier (NID) needs to be registered in accordance with the rules defined here, and the remaining parts of the assigned-name portion of the URN need to be generated in accordance with the rules for the registered URN namespace.

This makes it very hard to provide valid URNs for the id property, as one needs to register a URN namespace at IANA.
Possible solution
IMHO the recommendation of using a URN should be changed to using an identifier that starts with a reverse-DNS name. Doing so would still make it possible to have unique IDs for AsyncAPI specs while not having to hassle with invalid URNs. Using a reverse-DNS prefixed id is a common pattern.

Relates to https://github.com/asyncapi/spec/pull/718 (not the same)

It is not very clear to me, by the RFC, that informal URN namespaces should be registered as they already have the :urn{1-7} assigned.
Are you sure about that (asking because I have no idea)?

By RFC 8141, even the informal URN namespace identifiers (NIDs) are meant to be registered with IANA. Section 5.2 says

the registrant does not designate the NID; instead, IANA assigns the NID

And section 7.2 says

In all cases, the IANA ought to assign the appropriate NID (formal or informal) once the procedures outlined in Section 6 have been completed.

So even an informal URN would need to be registered and, using a hypothetical informal URN namespace "8", would look something like urn:urn-8:com:smartylighting:streetlights:server
For what it's worth, I suggest keeping the requirement that the id must conform to the URI format, but I suggest changing the recommendation.
I suggest recommending the tag URI scheme to get the benefit of "identify[ing] the application during long periods of time, even after it becomes unavailable or ceases to exist,"
I recognize there are several examples of URNs with unregistered NIDs in other products and systems. Those usages were created before RFC8141 obsoleted RFC2141 in 2017. RFC2141 didn't require namespace identifiers to be registered with IANA, while RFC 2611 and RFC 3406 that described the registration process were only "Best current practices" documents. But a new industry standard like AsyncAPI should follow the latest standards-track RFC for URNs and respect the registration requirement.


Add a delay in updateGraphiteData before making the backend call

Cabot seems to be making a backend call for each keypress when checking the metric values. This was bugging me, so  just added a delayed timeout to smooth this out a bit.
This this change, we'll be making less backend calls when updating metrics (hopefully enough time for the user to finish the metrics they were hoping to create the alert on)

Had a look with @MrSaints − merging!


openstack: include support to metadata service

In most cases, OpenStack metadata service is available in the cloud,
which removes the requirement of config-drive.
This patch will change the logic to try reading Metadata and Network data from
the config-drive directory but if it's not present, it'll try to get
it by safely fetching the URL.
Note: it's adding a new dependency on hashicorp/go-retryablehttp which
is a library which provides a HTTP client interface with automatic retries
and exponential backoff.

It worked fine to fetch the metadata service:
I0301 18:00:41.740862   49272 utils_virtual.go:105] ReadOpenstackMetaData(): read OpenStack meta_data from config-drive
2022/03/01 18:00:41 [DEBUG] GET http://<IP_ADDRESS>/openstack/2018-08-27/meta_data.json
2022/03/01 18:00:41 [DEBUG] GET http://<IP_ADDRESS>/openstack/2018-08-27/network_data.json

/lgtm
this looks good to me. Thanks!

@SchSeba can you take a look on this PR? Thanks

LGTM

In most cases, OpenStack metadata service is available in the cloud

should fetching from metadata service be the default ?

In most cases, OpenStack metadata service is available in the cloud

should fetching from metadata service be the default ?

Using config-drive is considered more stable than using metadata, that's why we try to handle it first.
The order chosen was initially proposed by @EmilienM, maybe he has more information about it.

In most cases, OpenStack metadata service is available in the cloud

should fetching from metadata service be the default ?

Using config-drive is considered more stable than using metadata, that's why we try to handle it first. The order chosen was initially proposed by @EmilienM, maybe he has more information about it.

Right, let's try to read the files first (cheaper & faster than fetching URL), by default, and if it's not there we just fallback into fetching the metadata URL.

@adrianchiris Thanks for the review. Can you take another look on this PR?

/test-all

LGTM

/test-all

/lgtm


Update README.md #1317

https://github.com/akshitagupta15june/Moksh/issues/1317 for any change i am ready to change review it and please merge it

@akshitagupta15june


Layout of the GDS image link leads to 404

F´ Version

Affected Component
fprime-community/fprime-gds/README.md

Problem Description
Image link "The layout of the GDS" leads to Page Not Found.
How to Reproduce

Follow "The layout of the GDS" in fprime-gds/README.md

Expected Behavior
Shows an image of the layout of the GDS.

Fixed by https://github.com/fprime-community/fprime-gds/pull/110


Expression 'undefined' in attribute 'dataurl' used with directive 'signaturePad' is non-assignable

I'm getting this weird console error sometimes whenever I write on the signature canvas.
The signature is working correctly and saving as it's suppose to but this pops up now and then.
<signature-pad accept="accept" clear="clear" ng-model="signature" height="220" width="568"></signature-pad>
          <button ng-click="clear()">Clear signature</button>
          <button ng-click="signature = accept(); checkSign(signature)">Sign</button>

add dataurl="" to the element of signature-pad

@kevinsuzc Thanks for you comment.
I'll leave this ticket open, because dataurl should be optional.

This is already reported #14


Update to work with Django 1.8

Django 1.5 and 1.6 are no longer supported by the Django developers. Django 1.4 has security fixes until October 2015 (https://www.djangoproject.com/download/). It therefore seems like a good time to update the versions of Django we support (also see #226 #217).

Implemented in PR #250


Warn the user when testing configuration is not complete

On behalf of @qubitron
Repo: github.com/qubitron/hello-stackoverflow
Scenario 1

Enable unit tests (do not configure the args)
Running and discovering tests fail

Suggestion: Check if args are empty, if they are, then display a prompt to configure test framework
~Other errors~

~Testing with PyTest failed~
~Debug adapter failed regularly leaving extension in a bad state (requiring restart of VS Code)~

~Status bar had a message running tests (this never went away)~
~Debugger bar appeared on the top (clicking stop did nothing)~
~Debug adapter failed with usual message Debug adapter failed unexpectedly~

~Deleting Experimental Debugger configuration settings from launch.json fixed a lot of the issues~

Todo:

Improve error handling and logging (diagnosing)
User should never have to reload VS Code
~* Recover from a state where debugger has a message running tests~

This issue depends on https://github.com/Microsoft/vscode-python/issues/1068

@DonJayamanne I tweaked the title to try and reflect what I think the issue is. Basically this is if "python.unitTest.unittestEnabled": true but "python.unitTest.unittestArgs" is unset?

Affirmative

this isn't an issue anymore, is it? @DonJayamanne

Will need to be confirmed

I set up pytest and then removed the "python.testing.pytestArgs" setting.  I did not get prompted to update my settings.

I'd say it's a feature request rather than a bug. The configuration process for tests is not left incomplete when it's done through the extension. It only gets to that state if we manually change it.

I'm going to close the issue, because even if the configuration is done manually, and only the value of "unittestEnabled" is updated, when trying to run the tests, it shows this:

In other words, it shows you that the configuration is wrong or incomplete and suggests you do it again.


ARM support implementation

There was an issue (#118) tracking arm support but it was closed without explanation. We need an issue which is open to track the implementation.
Can someone who is familiar with the existing implementation give some insight into what exactly are the technical hurdles? I have the time and inclination to work on this but would appreciate a basic orientation of what to look at.

#118 looks still open to me. I don't know about technical hurdles, I'm not familiar with the ARM architecture.

This.......... can be closed. Lol


[Bug]: Bedrock: Iterator value A is not an entry object

What happened?
Picking and using some of the Bedrock models (e.g. ai21.jamba-instruct-v1:0) causes UI errors: Something went wrong. Here's the specific error message we encountered: An error occurred while processing your request. Please contact the Admin.
Steps to Reproduce (use latest LibreChat from Github main )

Submit a prompt to verify the model works
Pick model ai21.jamba-instruct-v1:0 and submit a prompt
note error
Switch back to previously functioning model and submit prompt
note error

What browsers are you seeing the problem on?
Firefox
Relevant log output
2024-09-14 18:31:26 info: Server listening on all interfaces at port 3080. Use http://localhost:3080 to access it
2024-09-14 18:36:53 error: [api/server/controllers/agents/client.js #sendCompletion] Unhandled error type The provided model identifier is invalid.
2024-09-14 18:36:53 error: [handleAbortError] AI response error; aborting request: The provided model identifier is invalid.
2024-09-14 18:38:23 error: [api/server/controllers/agents/client.js #sendCompletion] Unhandled error type Iterator value A is not an entry object
2024-09-14 18:38:23 error: [handleAbortError] AI response error; aborting request: Iterator value A is not an entry object

Screenshots

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Can't reproduce:

Switched bedrock models, switched endpoints,
Working here, looks like this previous issue already addressed?
https://github.com/danny-avila/LibreChat/issues/4006

The root of the issue is this:

2024-09-14 18:36:53 error: [handleAbortError] AI response error; aborting request: The provided model identifier is invalid.

You may be trying to use a model only available to you in a specific region?
To really account for this, you need to make use of presets. Some backend feature to determine this for you would still need to be implemented.

There was no way i could get this to work at us-west-2, so i am now yanking out the ai21.jamba-instruct-v1:0 model
sed -i "/^[[:space:]]*'ai21.jamba-instruct-v1:0',/s/^[[:space:]]*/&\/\/ /" \
              ${LIBRECHAT_PATH}/packages/data-provider/src/config.ts

and now run with "npm run backend" under systemd instead of docker.


coc contains INSERT CONTACT METHOD

Issue: Document contains [INSERT CONTACT METHOD].
Ideas: Perhaps there can be a way in one's project to configure things in bake-modernize (so that this could BE a placeholder).
Like a .bake-modernizerc, perhaps?

FYI, we can shove data into gemspec metadata, anything we want, so we can use it for this too.


Sketch 49.1  unable to mark and export

Sketch Measure 2.7.7
Sketch 49.1
I have install Measure,but when i mark or export, it can not work!

@LiSunny with Sketch 49.1, I believe you will need to downgrade to Measure 2.7.4 or 2.7


Use travis container-based infrastructure

This should speed up the Travis CI testing significantly.

Nevermind, I guess this project was created after the big travis switchover (2015-01-01), so this isn't needed.


Angular Proxy not forwarding if response code 204 received from backend

Which @angular/* package(s) are the source of the bug?
Don't known / other
Is this a regression?
Yes
Description
Using a simple proxy configuration:
{
    "/api": {
        "target": "https://<backend domain>",
        "secure": false,
        "changeOrigin": true,
        "logLevel": "debug",
        "pathRewrite": {"^/api" : "https://<backend domain>/api"}
    },

The proxy responds correctly to any request. Except if that request happens to respond with a 204 and no body.
CURLing to the backend directly delivers the following:
[...request omitted...]
> content-length: 23
>
* We are completely uploaded and fine
* [CONN-0-0][CF-SSL] TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* [CONN-0-0][CF-SSL] TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 204
< date: Fri, 29 Nov 2024 13:52:15 GMT
< vary: Accept-Language, Cookie
< content-language: de
< x-content-type-options: nosniff
< referrer-policy: same-origin
< x-frame-options: DENY
< set-cookie: language=de; Path=/; Secure
< set-cookie: ###REDACTED###
< strict-transport-security: max-age=15724800; includeSubDomains
<
* Connection #0 to host ###REDACTED### left intact

The same request to the angular proxy on localhost:
[...request omitted...same as above]
> Content-Length: 23
>

...and that's it. i do control the backend somewhat, so i changed my response to a 200 with json encoded "OK" as answer. That works with the proxy:
[...request omitted...same as above]
> Content-Length: 23
>
* [CONN-0-0][CF-SSL] TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* [CONN-0-0][CF-SSL] TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< X-Powered-By: Express
< Access-Control-Allow-Origin: *
< date: Fri, 29 Nov 2024 14:06:47 GMT
< content-type: application/json
< content-length: 4
< connection: close
< vary: Accept-Language, Cookie
< content-language: de
< x-content-type-options: nosniff
< referrer-policy: same-origin
< x-frame-options: DENY
< set-cookie: language=de; Path=/; Secure
< set-cookie: ###REDACTED###
< strict-transport-security: max-age=15724800; includeSubDomains
<
"OK"* Closing connection 0

just for completeness, the only difference i see in the server response for the 200 are these 4 headers:
< content-type: application/json
< content-length: 4
< vary: Accept-Language, Cookie
< content-language: de

these are present in the 200 answer, but not the 204 answer (which makes sense, because there is no body). Apparently, the angular proxy is waiting for these headers to be sent, but never receives them and is thus stuck in an infinite loop.
Since 204s are rather common for DELETE statements (in this case it's a POST, but the same happens with DELETE and any other method), it would be nice if this issue could be addressed.
Please provide a link to a minimal reproduction of the bug
No response
Please provide the exception or error you saw

Please provide the environment you discovered this bug in (run ng version)
Angular CLI: 18.2.12
Node: 18.20.3
Package Manager: npm 10.8.1
OS: win32 x64

Angular: 18.2.3
... animations, common, compiler, compiler-cli, core, forms
... language-service, localize, platform-browser
... platform-browser-dynamic, router, service-worker, upgrade

Package                            Version
------------------------------------------------------------
@angular-devkit/architect          0.1802.12
@angular-devkit/build-angular      18.2.12
@angular-devkit/core               18.2.12
@angular-devkit/schematics         18.2.12
@angular/cdk                       18.2.14
@angular/cli                       18.2.12
@angular/flex-layout               15.0.0-beta.42
@angular/material                  18.2.14
@angular/material-moment-adapter   18.2.14
@schematics/angular                18.2.12
rxjs                               7.8.1
typescript                         5.5.4
zone.js                            0.14.10

Anything else?
I Can't really pinpoint which update introduced this issue, we recently updated from angular-16 to 18. I'm pretty sure that this was not an issue in earlier versions. Also not sure what component to select above. is the proxy part of the compiler-cli?

This is not an Angular CLI bug as the proxy is handled by Vite or Webpack-dev-server dependencies. What I did notice is that the content length for your 204 response is 23 and not 0.

This is not an Angular CLI bug as the proxy is handled by Vite or Webpack-dev-server dependencies. What I did notice is that the content length for your 204 response is 23 and not 0.

no, that is the request body size (it's post with a payload)

@alan-agius4 so where should i direct this bug then? because as of now, this is posing a problem for us in angular development.

That depends on which builder you are using, are you using the esbuild/vite or webpack based?

That depends on which builder you are using, are you using the esbuild/vite or webpack based?

for all i know, i'm using "builder": "@angular-devkit/build-angular:dev-server" for serve. at version 18.2.3. No idea what's the underlying builder there.

@angular-devkit/build-angular:dev-server can use either vite and webpack-dev-server. What are you using as your build builder?

@angular-devkit/build-angular:dev-server can use either vite and webpack-dev-server. What are you using as your build builder?

@angular-devkit/build-angular:browser


Public Cloud: Add support for bootstrapping in Google Compute

(cherry picked from commit 446f412a3fd871bfae8429d9131fe462cbbb0d5e)

 Public Cloud: Add support for bootstrapping in Google Compute

Overall LGTM, requesting a review from other velum developers.

I can rebase it, if that's what's expected... if you all agree to put your reviews back in after :)

Rebasing made no change...

For reference, this is released code:
https://build.suse.de/package/view_file/SUSE:SLE-12-SP3:Update:Products:CASP21:PublicCloud/velum/0002-Add-support-for-bootstrapping-in-Google-Compute.patch?expand=1

What's the status of this PR?