Add dealReference to fetch_open_positions() - Closed position dealId no longer matches Open position dealId

This is probably mostly my own issue, but keen on feedback from anyone else:
I had a system working fine for a while but it seems IG now change the dealId shown on a closed position. This means that I can no longer match up closed positions with those in my database using the dealId.
IG also have a dealReference and the /positions endpoint returns it in the position object, but fetch_open_positions() does not include dealReference - https://github.com/ig-python/ig-markets-api-python-library/blob/master/trading_ig/rest.py#L538
I just checked the create_working_order() and that does seem to return fetch_deal_by_deal_reference() so I'm assuming that includes a deal reference that I can add to my orders and positions in my database so all should be good there.
I was probably using the API wrong myself as I believe the documentation says dealReference shouldn't change, unlike dealId which can.
I think all that needs to be done is to add dealReference to fetch_open_positions() but might be worth a quick check for any other places it might be missing.
I need to do some work on my own system to get dealReference into my database tables so will report any other findings and see if I can contribute my own changes.

@oliverpolden are you still seeing issues? The latest release has support for the /history/activity endpoints, which were not included at all previously. Can those functions help at all?

no response, closing

no response, closing


Allow JVM debug options to be configurable

Fixes  #18084
Context
nothing to add here :-)

Contributor Checklist

[x] Review Contribution Guidelines
[x] Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
[x] Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
[x] Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team
[x] Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
[x] Provide unit tests (under <subproject>/src/test) to verify logic
[x] Update User Guide, DSL Reference, and Javadoc for public-facing changes
[x] Ensure that tests pass sanity check: ./gradlew sanityCheck
[x] Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest

Gradle Core Team Checklist

[x] Verify design and implementation
[x] Verify test coverage and CI build status
[x] Verify documentation
[x] Recognize contributor in release notes

Sorry for the late reply; we'll take a look soon.

@octylFractal I've merged master branch into this PR and I've fixed naming in tests.

Thank you for your suggestions, I applied all of them.

@bot-gradle test and merge

Your PR is queued. See the queue page for details.

OK, I've already triggered a build for you.

Pre-tested commit build failed.

@bot-gradle test and merge

OK, I've already triggered a build for you.

Pre-tested commit build failed.

There is a test failure to be resolved first: https://builds.gradle.org/viewLog.html?buildId=47332274&tab=buildResultsDiv&buildTypeId=Gradle_Master_Check_Quick_1_bucket6

@bot-gradle test and merge

OK, I've already triggered a build for you.

Pre-tested commit build failed.

I'll take care of this later, seems like some of the tests don't like particular environments.

@bot-gradle test and merge

Your PR is queued. See the queue page for details.

OK, I've already triggered a build for you.

Pre-tested commit build failed.

@bot-gradle test and merge

OK, I've already triggered a build for you.

Pre-tested commit build failed.

@bot-gradle test and merge

OK, I've already triggered a build for you.

Pre-tested commit build failed.

@bot-gradle test and merge

Your PR is queued. See the queue page for details.

@bot-gradle test QF

OK, I've already triggered QuickFeedback build for you.

@bot-gradle test QF

OK, I've already triggered QuickFeedback build for you.

@bot-gradle test and merge

OK, I've already triggered a build for you.

Pre-tested commit build failed.

@bot-gradle test QF

OK, I've already triggered QuickFeedback build for you.

@bot-gradle test QF

OK, I've already triggered QuickFeedback build for you.

@bot-gradle test and merge

OK, I've already triggered a build for you.

@platan thank you for the contribution!

Thank you all for helping me with my first contribution to Gradle.


Workaround PHP bug #63206 in Stream::setStream method

Q
A

Branch?
master

Bug fix?
yes

New feature?
no

BC breaks?
no

Deprecations?
no

Tests pass?
yes

License
MIT

This PR fixes #298 by removing the usage of the second argument of the set_error_handler function and moves the check of the level of the raised error inside the error handler callback.

@ste93cry Umm... that's not the PR template we use... and the package is licensed BSD-3-Clause; we're not in a position to dual-license. Can you clarify the license before we merge, please?

Sorry I copy-pasted a template from another repository I used to contribute to. My code is released under any license you use, so feel free to do whatever you want.

Thanks, @ste93cry!


Fixes issue #249 Clarify the conceptual relationship to RDF-1.1

This PR addresses GitHub issue: #249
Briefly describe the changes proposed in this PR:

Clarify the relationship to the RDF-1.1 specification. In particular, clarify the status of Literal.getDatatype that cannot be null or empty in RDF-1.1 as it could be in RDF-1.0.

Make sure you've followed the Contributor Guidelines. In particular (please tick to indicate you've taken care of it):

[x] RDF4J code formatting has been applied
[ ] tests are included
[ ] all tests succeed

No code or contract changes, just clarifications in javadoc of the contracts that the existing RDF4J code already follows.

Looks good to me!

It looks good to me on rereading it too. I can't merge though so you merge when you think it is ready.


chore: update to semantic-release@18

semantic-release@18 requires at least<EMAIL_ADDRESS>Solution is either:

https://github.com/actions/runner/issues/772 being resolved
Converting this package to a docker action.

For now it looks like the action runs with semantic-release@18 without a problem when being built in node@>=14 environment.

2.0.1 (2022-04-26)
Bug Fixes

upgrade action environment to node16 (eca8895)


Fetching page data for upcoming livestream

[x] I'm reporting a site feature request
[x] I've verified that I'm running youtube-dl version 2021.04.01
[x] I've searched the bugtracker for similar site feature requests including closed ones

I'd like to pull metadata from a page with a scheduled livestream, but it seems I cannot (by metadata I mean channel name, title, description).
I'm running ytdl in conjunction with streamlink using a script that's meant to:

Create a recording directory with the channel name (fetched by ytdl)
record into there, ready for postprocessing

in the case of unarchived streams, this data can't be fetched later, so it really needs to be fetched before the stream begins recording. Is there a way to do this with ytdl as it exists, and if not, can it please be added?
(Please note I'm not trying to use ytdl to automatically download the stream, just page data)

Can confirm: Doesn't work on 2021.04.07


Something is blocking Hunterpie native to create a socket.

While HunterPie itself is working fine, all the plugins don't work at all. I've added it and the game to the firewall exceptions but it didn't help. I've even turned it off completely, but it didn't help either

I mean, you pretty much said what the issue is in the title, a socket not being created could have millions of different reasons, maybe your port is blocked, maybe something is blocking it, maybe it failed when trying to create the socket for whatever reason. Maybe the reason isn't even the server socket, maybe something is blocking the client, maybe the socket is dying too soon, I don't know, It's impossible to tell what the error is without any information.

Will the screenshot help?

No, that's just a generic error message from C#, it doesn't help because the error isn't coming out from the C# client, it's from the native part, which is just hard to debug unless you do it yourself by compiling the project as debug and running it so it will create a console when injecting the native into the game. It's a local problem, so not much I can do since I can't reproduce it.

So i was able to fix it by relocating the HunterPie folder. Idk why it helped but it did


Chart dependency with version range cannot be sorted

Chart dependencies specified using the recommended version range method are unable to be sorted.
Chart.yaml
apiVersion: v2
description: Example umbrella chart
type: application
name: example-umbrella-chart
version: "0.0.1"
maintainers:
  - name: Someone
    email<EMAIL_ADDRESS>dependencies:
- name: node-problem-detector
  repository: https://charts.deliveryhero.io
  version: "^2.3.11"

values.yaml
foo: bar

% helm-schema --version
helm-schema version 0.11.5

% helm-schema --log-level trace
WARN[2024-07-18T20:31:12+01:00] Could not sort results: circular or missing dependency found: map[example-umbrella-chart-0.0.1:Set{node-problem-detector-^2.3.11}] - Please build and untar all your helm dependencies: helm dep build && ls charts/*.tgz |xargs -n1 tar -C charts/ -xzf
DEBU[2024-07-18T20:31:12+01:00] Processing result for chart: example-umbrella-chart (Chart.yaml)
WARN[2024-07-18T20:31:12+01:00] Dependency (example-umbrella-chart->node-problem-detector) specified but no schema found. If you want to create jsonschemas for external dependencies, you need to run helm dependency build & untar the charts.

% helm dep build && ls charts/*.tgz |xargs -n1 tar -C charts/ -xzf
Getting updates for unmanaged Helm repositories...
...Successfully got an update from the "https://charts.deliveryhero.io" chart repository
...
Update Complete. ⎈Happy Helming!⎈
Saving 1 charts
Downloading node-problem-detector from repo https://charts.deliveryhero.io
Deleting outdated charts

% helm-schema --log-level trace
WARN[2024-07-18T20:32:01+01:00] Could not sort results: circular or missing dependency found: map[example-umbrella-chart-0.0.1:Set{node-problem-detector-^2.3.11}] - Please build and untar all your helm dependencies: helm dep build && ls charts/*.tgz |xargs -n1 tar -C charts/ -xzf
DEBU[2024-07-18T20:32:01+01:00] Processing result for chart: node-problem-detector (charts/node-problem-detector/Chart.yaml)
DEBU[2024-07-18T20:32:01+01:00] Processing result for chart: example-umbrella-chart (Chart.yaml)
DEBU[2024-07-18T20:32:01+01:00] Found chart of dependency node-problem-detector (charts/node-problem-detector/Chart.yaml)

Switching the version: constraint to a specific version resolves the issue.
Possibly relates to https://github.com/dadav/helm-schema/pull/30

This happens because it's using the version to identify the chart. This was necessary to fix #27. I need to find a way to identify a chart without the version field..

This happens because it's using the version to identify the chart. This was necessary to fix #27. I need to find a way to identify a chart without the version field..

Hm, this is tricky, especially given the expectation is that helm dep build has already been run. With a Chart.yaml like
# NOTE: This chart is for generic services, don't define appVersion
apiVersion: v2
description: Example umbrella chart
type: application
name: example-umbrella-chart
version: "0.0.1"
maintainers:
  - name: Someone
    email<EMAIL_ADDRESS>dependencies:
- name: node-problem-detector
  alias: dep-a
  repository: https://charts.deliveryhero.io
  version: "^2.3.11"
- name: node-problem-detector
  alias: dep-b
  repository: https://charts.deliveryhero.io
  version: "^1"

we end up with a Chart.lock like
dependencies:
- name: node-problem-detector
  repository: https://charts.deliveryhero.io
  version: 2.3.13
- name: node-problem-detector
  repository: https://charts.deliveryhero.io
  version: 1.8.7
digest: sha256:41dba0e364f30a9fa06247870f8d4fcb76f83a677ac4f8266ff5d3c43655c2de
generated: "2024-07-19T18:08:02.243846+01:00"

and it's unclear how exactly to tie the version-range dependency to the version-locked dependency. I wonder if we can rely on list position? If so we could perhaps parse the Chart.lock and use the version there as the resolved version for sorting/identification purposes?

Looks like Chart.lock dependencies are 1:1 with Chart.yaml dependencies, even if the resolved version is the same:
Chart.yaml
apiVersion: v2
description: Example umbrella chart
type: application
name: example-umbrella-chart
version: "0.0.1"
maintainers:
  - name: Someone
    email<EMAIL_ADDRESS>dependencies:
- name: node-problem-detector
  alias: dep-a
  repository: https://charts.deliveryhero.io
  version: "^2.3.11"
- name: node-problem-detector
  alias: dep-b
  repository: https://charts.deliveryhero.io
  version: "^1"
- name: node-problem-detector
  alias: dep-c
  repository: https://charts.deliveryhero.io
  version: "*"

Chart.lock:
dependencies:
- name: node-problem-detector
  repository: https://charts.deliveryhero.io
  version: 2.3.13
- name: node-problem-detector
  repository: https://charts.deliveryhero.io
  version: 1.8.7
- name: node-problem-detector
  repository: https://charts.deliveryhero.io
  version: 2.3.13
digest: sha256:a5eefbb0b6c38b3d2220e30ef8ee093e6b01d7fef8073a140145744b3162de6f
generated: "2024-07-19T18:12:06.434356+01:00"

Thanks for the quick fix.


Fixed typo in memory documentation

"sp11ecifying" has been corrected to "specifying"

That's a weird typo...
Thanks!


Cross-compilation tests

Based on the automatic detection of the resource/search directory, I think cross-compilation should "just work", but we should have some automated tests that it actually works.

cc @honghao12 -- are you able to test scip-clang for your use case? Apologies for just seeing the issue you opened in the lsif-clang repo. scip-clang tries to automatically add the right include directories (the error in https://github.com/sourcegraph/lsif-clang/issues/92 seems to be related to headers from your cross-compilation toolchain not being found). Can you check if that fixes your issue?


shared: Fix HostPathFollow for stdin/stdout

Signed-off-by: Stéphane Graber<EMAIL_ADDRESS>

Testsuite passed


[FEATURE] Allow customization of validation error

Is your feature request related to a problem
I’d like to globally customize validation errors by changing (overriding) the HTTPValidationError/ValidationError and the 422 status code.
The solution you would like
Something great would be adding some parameters to the FastAPI class:
from fastapi import FastAPI

from .models import ValidationError

app = FastAPI(
    validation_error_status_code=422,
    validation_error_model=ValidationError
)

Describe alternatives you've considered
What’s currently possible (to my knowledge) is adding an item with status code 422, 4XX or default in the responses dict, but this as to be done manually for every route that will perform validation. This also prevent changing the status code to a specific value (you can either stick with 422, or have something vague like default or 4XX).

Does this work for you? https://fastapi.tiangolo.com/tutorial/handling-errors/#override-request-validation-exceptions

Well it works regarding what’s produced by the API, but it doesn’t regarding documentation.

I have hit a similar issue previously and solved it by modifying the OpenAPI spec 'manually' like it's been suggested in some previous issues.
However, I think it would be useful if you could add 'additional status codes' and/or 'additional responses' to a APIRouter() instance, which would add them to all of the routes automatically.

Extending OpenAPI manually seems a bit complicated to me.
HTTP 422 is hardcoded in openapi/utils.py. I solved my issue for now by modifying the FastAPI source code itself, but a proper way to do this automatically using the exception handlers would be preferable.

Hey @tiangolo,
I would like to work on this feature.
Do you think that it's a good idea?
Any tips or concerns?

The solution that would require less work and have bigger chances on being approved (based only on what I've seen here) is creating a flag to not add the 422 response in the swagger documentation.
The custom exception handler already handles the first problem described.

The solution that would require less work and have bigger chances on being approved (based only on what I've seen here) is creating a flag to not add the 422 response in the swagger documentation.
The custom exception handler already handles the first problem described.

@Kludex thanks for the quick response.
It works for me and I think this is the only blocker for proper customizing the RequestValidationError into a custom response format.

If all you errors follow the same schema, and provided you implemented the custom handler described in https://fastapi.tiangolo.com/tutorial/handling-errors/#override-request-validation-exceptions, you can just override the default schema in openapi/utils.
For example if I take the example server from the docs:
from typing import Optional
from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def read_root():
    return {"Hello": "World"}

@app.get("/items/{item_id}")
def read_item(item_id: int, q: Optional[str] = None):
    return {"item_id": item_id, "q": q}

it will present the default schema il http://localhost:8000/docs:

But if I just overwrite the validation_error_response_definition in the fastapi.openapi.utils module it changes the default schema used by OpenAPI:
from typing import Optional
from fastapi import FastAPI

# import the module we want to modify
import fastapi.openapi.utils as fu

app = FastAPI()

# and override the schema
fu.validation_error_response_definition = {
    "title": "HTTPValidationError",
    "type": "object",
    "properties": {
        "error": {"title": "Message", "type": "string"},
    },
}

@app.get("/")
def read_root():
    return {"Hello": "World"}

@app.get("/items/{item_id}")
def read_item(item_id: int, q: Optional[str] = None):
    return {"item_id": item_id, "q": q}

gives:

If all you errors follow the same schema, and provided you implemented the custom handler described in https://fastapi.tiangolo.com/tutorial/handling-errors/#override-request-validation-exceptions, you can just override the default schema in openapi/utils.
For example if I take the example server from the docs:
from typing import Optional
from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def read_root():
    return {"Hello": "World"}

@app.get("/items/{item_id}")
def read_item(item_id: int, q: Optional[str] = None):
    return {"item_id": item_id, "q": q}

it will present the default schema il http://localhost:8000/docs:

But if I just overwrite the validation_error_response_definition in the fastapi.openapi.utils module it changes the default schema used by OpenAPI:
from typing import Optional
from fastapi import FastAPI

# import the module we want to modify
import fastapi.openapi.utils as fu

app = FastAPI()

# and override the schema
fu.validation_error_response_definition = {
    "title": "HTTPValidationError",
    "type": "object",
    "properties": {
        "error": {"title": "Message", "type": "string"},
    },
}

@app.get("/")
def read_root():
    return {"Hello": "World"}

@app.get("/items/{item_id}")
def read_item(item_id: int, q: Optional[str] = None):
    return {"item_id": item_id, "q": q}

gives:

I would like this feature too, because it took more time to make it work than I wanted to 😞
Here is a less hacky way to do it.
You can override the 422 response type globally when instantiating FastAPI application with the responses parameter:
app = FastAPI(
    exception_handlers=(RequestValidationError, validation_exception_handler),
    responses={
        422: {"content": change_422_schema({})},
     },
)

First, you need to implement the RequestValidationError handler:

class Error(BaseModel):
    type: str
    detail: str
    location: Optional[List[str]] = None

# We only need this class for FastApi in the responses parameter for path decorators
class ErrorResponse(BaseModel):
    errors: List[Error]

def validation_exception_handler(request: Request, exc: RequestValidationError):
    """Format the pydantic ValidationErrors in a more human-readable way."""
    error_res = ErrorResponse(
        errors=[
            Error(type=err["type"], detail=err["msg"], location=err["loc"])
            for err in exc.errors()
        ]
    )
    return _make_json_response(status.HTTP_422_UNPROCESSABLE_ENTITY, error_res)

Then, you need to modify the responses dict content, which will make it directly to the OpenAPI schema, by changing the "application/json" / "schema" / "$ref" value to your own Error type name:
def change_422_schema(content: dict):
    """Change the ValidationError's schema to make it consistent with the rest of our API."""
    new_content = content.copy()
    content_type = new_content.setdefault("application/json", {})
    content_type["schema"] = {"$ref": REF_PREFIX + ErrorResponse.__name__}
    return new_content

So the 422 responses will be in the proper format and the generated OpenAPI schema will show the exact model and there will be no leftover models from FastAPI.

I would like this feature too, because it took more time to make it work than I wanted to 😞
Here is a less hacky way to do it.
You can override the 422 response type globally when instantiating FastAPI application with the responses parameter:
app = FastAPI(
    exception_handlers=(RequestValidationError, validation_exception_handler),
    responses={
        422: {"content": change_422_schema({})},
     },
)

First, you need to implement the RequestValidationError handler:

class Error(BaseModel):
    type: str
    detail: str
    location: Optional[List[str]] = None

# We only need this class for FastApi in the responses parameter for path decorators
class ErrorResponse(BaseModel):
    errors: List[Error]

def validation_exception_handler(request: Request, exc: RequestValidationError):
    """Format the pydantic ValidationErrors in a more human-readable way."""
    error_res = ErrorResponse(
        errors=[
            Error(type=err["type"], detail=err["msg"], location=err["loc"])
            for err in exc.errors()
        ]
    )
    return _make_json_response(status.HTTP_422_UNPROCESSABLE_ENTITY, error_res)

Then, you need to modify the responses dict content, which will make it directly to the OpenAPI schema, by changing the "application/json" / "schema" / "$ref" value to your own Error type name:
def change_422_schema(content: dict):
    """Change the ValidationError's schema to make it consistent with the rest of our API."""
    new_content = content.copy()
    content_type = new_content.setdefault("application/json", {})
    content_type["schema"] = {"$ref": REF_PREFIX + ErrorResponse.__name__}
    return new_content

So the 422 responses will be in the proper format and the generated OpenAPI schema will show the exact model and there will be no leftover models from FastAPI.

I am doing something simpler. Just removing any ref to the error 422 in the generated OpenAPI dict:
from fastapi import FastAPI
from fastapi.openapi.utils import get_openapi
from fastapi.exceptions import RequestValidationError

app = FastAPI()

@app.get("/items/")
async def read_items():
    return [{"name": "Foo"}]

@app.exception_handler(RequestValidationError)
async def validation_exception_handler(request, exc):
    """Your custom validation exception."""
    message =
    return JSONResponse(
        status_code=code,
        content={"message": f"Validation error: {exc}"}
    )

def custom_openapi():
    if app.openapi_schema:
        return app.openapi_schema
    openapi_schema = get_openapi()

    # look for the error 422 and removes it
    for method in openapi_schema["paths"]:
        try:
            del openapi_schema["paths"][method]["post"]["responses"]["422"]
        except KeyError:
            pass

    app.openapi_schema = openapi_schema
    return app.openapi_schema

app.openapi = custom_openapi

I am doing something simpler. Just removing any ref to the error 422 in the generated OpenAPI dict:
from fastapi import FastAPI
from fastapi.openapi.utils import get_openapi
from fastapi.exceptions import RequestValidationError

app = FastAPI()

@app.get("/items/")
async def read_items():
    return [{"name": "Foo"}]

@app.exception_handler(RequestValidationError)
async def validation_exception_handler(request, exc):
    """Your custom validation exception."""
    message =
    return JSONResponse(
        status_code=code,
        content={"message": f"Validation error: {exc}"}
    )

def custom_openapi():
    if app.openapi_schema:
        return app.openapi_schema
    openapi_schema = get_openapi()

    # look for the error 422 and removes it
    for method in openapi_schema["paths"]:
        try:
            del openapi_schema["paths"][method]["post"]["responses"]["422"]
        except KeyError:
            pass

    app.openapi_schema = openapi_schema
    return app.openapi_schema

app.openapi = custom_openapi

As this is still the topic... For all of you, who, like me, just want to change the status code to 400, but keep the default response schema AND still have it in the OpenAPI Docs, without the default 422... :D Here it goes...
Firstly, you describe your Pydantic models, like the original (used only for docs):
from pydantic import BaseModel
from typing import Optional, List

class Error(BaseModel):

    loc: Optional[List[str]] = None
    msg: str
    type: str

class ErrorResponse(BaseModel):
    detail: List[Error]

Then you use Pydantic model ErrorResponse in responses when defining your app:
app = FastAPI(title="My API", description="Some description here",
                     responses={status.HTTP_400_BAD_REQUEST: {"model": ErrorResponse}})

Then you override the default exception handler (like in the tutorial):
from fastapi.exceptions import RequestValidationError
from fastapi.responses import JSONResponse
from fastapi.encoders import jsonable_encoder

@app.exception_handler(RequestValidationError)
async def validation_exception_handler(request, exc):
    return JSONResponse(content=jsonable_encoder({"detail": exc.errors()}),
                        status_code=status.HTTP_400_BAD_REQUEST)

With this, you will have 400 normally documented for all your routes.
If you want to remove all 422 codes from the documentation, you need to exchange the default OpenAPI schema, similar to how @tupui  wrote above, or according to the tutorial here. Therefore, after defining all your path routes, add the following:
def custom_openapi():
    if app.openapi_schema:
        return app.openapi_schema
    openapi_schema = get_openapi(
        title=app.title,
        version=app.version,
        routes=app.routes
    )

    http_methods = ["post", "get", "put", "delete"]
    # look for the error 422 and removes it
    for method in openapi_schema["paths"]:
        for m in http_methods:
            try:
                del openapi_schema["paths"][method][m]["responses"]["422"]
            except KeyError:
                pass

    app.openapi_schema = openapi_schema
    return app.openapi_schema

app.openapi = custom_openapi

However, this works for the default API with no additional root paths. In order to make it work for such scenario, or when you want this to work only on the mounted API, you have to add servers to the openapi_schema as well, to have the proper routing in Swagger/Redoc. For example:
def custom_openapi():
    if app.openapi_schema:
        return app.openapi_schema
    openapi_schema = get_openapi(
        title=app.title,
        version=app.version,
        routes=app.routes,
        servers=[{
            "url": "/subapi"
        }]
    )
    # the rest as above

Hope this helps! 😄
Thanks again @tiangolo for all the awesome work on the framework! 🚀

In my application ovverhide the 422 error for 400, and overhide the responses errors for all api for the example: message: { field_error: message_error}
def get_message(root: str, fields: list, error_message: str, return_message=None):
    return_message = return_message or {}

    if root not in return_message:
        return_message[root] = {}

    for i, field in enumerate(fields):
        if len(fields) == 1:
            return_message[root].update({field: error_message})
        else:
            new_fields = fields.copy()
            del(new_fields[i])
            response = get_message(
                root=field, fields=new_fields,
                error_message=error_message, return_message=return_message[root]
            )
            return_message[root].update(response)
            break

    return return_message

And the method bellow is the rewrite exception_handlers={RequestValidationError: validation_bad_request_exception_handler}
async def validation_bad_request_exception_handler(request, exc):
    message = {}
    for x in exc.errors():
        fields = [entry for entry in x['loc'] if entry != 'body']

        if len(fields) == 0:
            message.update({'error': 'invalid request'})
        elif len(fields) == 1:
            message.update({fields[0]: x['msg']})
        else:
            # for dict / list with errors inside it
            field_root = fields[0]
            del(fields[0])

            message = get_message(
                root=field_root,
                fields=fields,
                error_message=x['msg'],
                return_message=message
            )

    return JSONResponse(
        status_code=400,
        content={
            "message": message,
        },
    )

Its work fine for me =D
It is just missing to change the documentation

I would like this feature too, because it took more time to make it work than I wanted to
Here is a less hacky way to do it.
You can override the 422 response type globally when instantiating a FastAPI application with the responses parameter:
app = FastAPI(
    exception_handlers=(RequestValidationError, validation_exception_handler),
    responses={
        422: {"content": change_422_schema({})},
     },
)

Then, you need to modify the responses dict content, which will make it directly to the OpenAPI schema, by changing the "application/json" / "schema" / "$ref" value to your own Error type name:
from fastapi.openapi.constants import REF_PREFIX

def change_422_schema(content: dict):
    """Change the ValidationError's schema to make it consistent with the rest of our API."""
    new_content = content.copy()
    content_type = new_content.setdefault("application/json", {})
    content_type["schema"] = {"$ref": REF_PREFIX + ErrorResponse.__name__}
    return new_content

So the 422 responses will be in the proper format and the generated OpenAPI schema will show the exact model and there will be no leftover models from FastAPI.

I did similar for a single router but slightly simpler
app = FastAPI(...)
app.include_router(
api_router,
prefix=settings.API_V1_STR,
responses={
422: {
"description": "Validation Error",
"model": ErrorResponse
}
}
)

Following up on @ushu excellent simple solution,
I would like to add that you could directly fetch the schema from your error model, ensuring consistent behavior between your response and its documentation.
from pydantic import BaseModel, Field
from fastapi import FastAPI

# define or import your error response model
class ErrorResponse(BaseModel):
    message: str = Field(..., example="message to the developer")
    error: str = Field(..., example="Validation Error")
    detail: dict = Field(..., example=[
        {'loc': 'quantity',
         'msg': 'value is not a valid integer',
         'type':'type_error.integer'}])

# override fastapi 422 schema
import fastapi.openapi.utils as fu
fu.validation_error_response_definition = ErrorResponse.schema()

app = FastAPI()

Gives:

Even though following some great examples here, it took me time to make it work as I wanted. I attempted to make it as simple as possible for newcomers (like me) to grasp.
Initially, we should implement the RequestValidationError handler, like so:
from typing import List

from fastapi import FastAPI, Request, status
from fastapi.encoders import jsonable_encoder
from fastapi.exceptions import RequestValidationError
from fastapi.responses import JSONResponse
from pydantic import BaseModel

class Error(BaseModel):
    message: str
    type: str

class ErrorResponse(BaseModel):
    detail: List[Error]

def validation_exception_handler(request: Request, exc: RequestValidationError):
    """
    Format the pydantic ValidationErrors in a more human-readable way.
    """
    errors = {
        "detail": [
            {
                "message": err["msg"],
                "type": err["type"],
            }
        ]
        for err in exc.errors()
    }
    error_res = ErrorResponse(**errors)
    return JSONResponse(
        content=jsonable_encoder(error_res.detail[0]),
        status_code=status.HTTP_422_UNPROCESSABLE_ENTITY,
    )

Then we have to override the 422 response when instantiating the FastAPI application with the responses and exception_handlers parameters, like so:
app = FastAPI(
    exception_handlers={RequestValidationError: validation_exception_handler},
    responses={
        422: {
            "description": "Validation Error",
            "model": ErrorResponse,
        },
    },
)

And now it will present our new schema:

I'm setting a custom openapi schema and this works fine when I export the openapi schema as JSON and feed it into e.g. redoc-cli which builds the redoc-static.html.
But these customizations to the openapi schema is not reflected in FastAPI when I access e.g. http://localhost/redoc. Is there any way I can have the cake and eat it?


Error -- Failed to update instance

Could you pleaes check this isssue. I am note able to run the jobs on broccoli..
Please help me to resolve the issue.
Failed to update instance: "java.net.URISyntaxException: Illegal character in scheme name at index 0: <IP_ADDRESS>:4646/v1/jobs" -- broccoli browser
[ERROR] [application-akka.actor.default-dispatcher-3] [d.f.b.c.WebSocketController] - Message handler threw exception for message GetInstanceTasks(test): scheme
java.lang.NullPointerException: scheme -- terminal

The URL format is <scheme>://<ip>:<port>. Try using http://<IP_ADDRESS>:4646 as your nomad URL in your conf.

Thasnks for the quick responce.
I have used  th below docker command only
docker run -p 9000:9000 frosner/cluster-broccoli
-Dbroccoli.nomad.url=<IP_ADDRESS>:4646
-Dbroccoli.consul.url=<IP_ADDRESS>:8500
Please help me.

Now i got new error:
Failed to update instance: "de.frosner.broccoli.services.NomadRequestFailed: Nomad request http://<IP_ADDRESS>:4646/v1/jobs failed. Status code 500"
could you please check it

09:26:54.777 [INFO] [application-akka.actor.default-dispatcher-5] [d.f.broccoli.services.NomadService] - Sending job definition to http://<IP_ADDRESS>:4646/v1/jobs
09:26:54.798 [ERROR] [application-akka.actor.default-dispatcher-5] [d.f.b.services.InstanceService] - Error updating instance: de.frosner.broccoli.services.NomadRequestFailed: Nomad request http://<IP_ADDRESS>:4646/v1/jobs failed. Status code 500

I am sorry but this seems unrelated. You need to check your nomad logs for this.


[BUG] Fargate only cluster creates "default" fargate profile without asking/configuring it

Trying to create a Fargate only cluster with single fargate profile, results in 2 fargate profiles that are being created: the configured one, and another one called default targeting kube-system and default namespaces
Configurations snippet

        const fargateProfiles: Map<string, eks.FargateProfileOptions> = new Map([
            ["base-profile", { selectors: [{ namespace: "kube-system" }, { namespace: "karpenter" }] }],

        ]);
        const fargateClusterProvider = new ssp.FargateClusterProvider({
            fargateProfiles,
            version: clusterVersion
        });

        const blueprint = ssp.EksBlueprint.builder()
            .account(PIPELINE_ENV.account)
            .region(PIPELINE_ENV.region)
            .withBlueprintProps({
                version: clusterVersion,
            })
            .clusterProvider(fargateClusterProvider)

Same happened to me..

This works as designed. The behavior is similar to ekscstl --fargate behavior. See more here.
You can leverage the generic cluster provider to configure arbitrary fargate profiles.

I was facing the same today. I don't want a default Fargate profile (Only one for the Karpenter namespace). Using the generic Cluster Provider it's easy to solve this:
    const clusterProvider = new blueprints.GenericClusterProvider({
      version: eks.KubernetesVersion.V1_21,
      fargateProfiles: {
        karpenter: {
          fargateProfileName: 'karpenter',
          selectors: [{ namespace: 'karpenter' }],
        },
      },
    });

However, we might want to explicitly call out the 'default' behaviour in the documentation when leveraging. FargateClusterProvider


Feature/au 1085 fix dates

AU-1085

What was done

Datetimes have been converted to date fields properly

How to install

Make sure your instance is up and running on correct branch.

git checkout feature/AU-1085-fix-dates
make fresh

Run make drush-cr

How to test

[ ] Check that this feature works (forms have normal datepicker fields)
[ ] Check that the new date fields map to avustus2 correctly (they were datetime before, that might cause issues)
[ ] Check that code follows our standards

Designers review

[x] This PR does not need designers review
[ ] This PR has been visually reviewed by a designer (Name of the designer)

Other PRs

Link to other PR

On niin pahoja konflikteja tossa kehittämisavustuksessa, etten selviä niistä ku en ymmärrä mikä on oikea muutos ja mikä ei.
Jos tsekkaat ton kuntoon ni ihmettelen sit. Ettei nyt taas sotketa paikkoja.

			{ 			  "ID": "projectStartDate", 			  "label": "Hanke alkaa", 			  "value": "2022-01-31T21:00:00.000", 			  "valueType": "datetime" 			}, 			{ 			  "ID": "projectEndDate", 			  "label": "Hanke päättyy", 			  "value": "2022-08-30T21:00:00.000", 			  "valueType": "datetime" 			},
Funny thing is that the data IS datetime in schema.


Revert "Use DebounceInput wrapper for fully controlled Editable"

Reverts reflex-dev/reflex#1650
Didn't really work after trying a fully controlled case with editable.

The approval was lost, one more time please @masenf


[stable/kong] problem running Kong with Postgres DB

Describe the bug
Since the change of Kong version from 0.26.1 to 0.27.0, I am not able to run Kong on Kubernetes using Helm. I've seen that the default database is off now.
Version of Helm and Kubernetes:
Helm
version.BuildInfo{Version:"v3.0.0", GitCommit:"e29ce2a54e96cd02ccfce88bee4f58bb6e2a28b6", GitTreeState:"clean", GoVersion:"go1.13.4"}

Kubernetes
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.3", GitCommit:"b3cbbae08ec52a7fc73d334838e18d17e8512749", GitTreeState:"clean", BuildDate:"2019-11-14T04:24:34Z", GoVersion:"go1.12.13", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.2", GitCommit:"c97fe5036ef3df2967d086711e6c0c405941e14b", GitTreeState:"clean", BuildDate:"2019-10-15T19:09:08Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}

Which chart:
stable/kong
What happened:
If I install Kong without database
helm install my-kong \
--set image.tag=1.4.0 \
--set admin.useTLS=false \
--set readinessProbe.httpGet.scheme=HTTP \
--set livenessProbe.httpGet.scheme=HTTP \
stable/kong

The pod gets UP and RUNNING but I am getting an error while creating a service in kong for my application
HTTP/1.1 405 Not Allowed
{"name":"operation unsupported","message":"cannot create 'services' entities when not using a database","code":12}

On the other hand, when I try to configure the postgres database
helm install my-kong \
--set image.tag=1.4.0 \
--set postgresql.enabled=true \
--set env.database=postgres \
--set admin.useTLS=false \
--set readinessProbe.httpGet.scheme=HTTP \
--set livenessProbe.httpGet.scheme=HTTP \
stable/kong

the pod never gets to RUNNING status
my-kong-kong-c88f76f59-vztwk         0/2     Init:0/1           0          103s
my-kong-kong-init-migrations-728t6   0/1     CrashLoopBackOff   3          103s

Am I missing any property above? Is that the correct configuration?

That is where I am having problem. If I spin up my own Postgres DB (as explained at Anything else we need to know) it works. However, if I set postgresql.enabled=true, i.e, ask for Kong helm to spin up a Postgres DB for me (as explained at **How to reproduce it **), Kong doesn't start.

yes,  I failed start kong too.
If you set
 pg_password:
       valueFrom:
         secretKeyRef:
            key: kong
            name: postgres

the job/xxx-kong-init-migrations will complected.
[root@node1 kong]# kubectl logs job/apigw-kong-init-migrations
Database already bootstrapped

But the kong pod will pending on "PodInitializing"
Init Containers:
  wait-for-db:
    Container ID:  docker://f834ce595a5b5addb0006b8628d7585800886b6227a2005ff10143d5437e3441
    Image:         kong:1.3
    Image ID:      docker-pullable://kong@sha256:664fb9a9bd06632d64274bc158066787108038d59036abb01db63ffd3dfc0fdd
    Port:          <none>
    Host Port:     <none>
    Command:
      /bin/sh
      -c
      until kong start; do echo 'waiting for db'; sleep 1; done; kong stop
    State:          Running
      Started:      Thu, 28 Nov 2019 15:05:56 +0800
    Ready:          False
    Restart Count:  0
    Environment:
      KONG_PG_HOST:                 apigw-postgresql
      KONG_PG_PORT:                 5432
      KONG_LUA_PACKAGE_PATH:        /opt/?.lua;;
      KONG_PG_PASSWORD:             <set to the key 'postgresql-password' in secret 'apigw-postgresql'>  Optional: false
      KONG_ADMIN_ACCESS_LOG:        /dev/stdout
      KONG_ADMIN_ERROR_LOG:         /dev/stderr
      KONG_ADMIN_GUI_ACCESS_LOG:    /dev/stdout
      KONG_ADMIN_GUI_ERROR_LOG:     /dev/stderr
      KONG_DATABASE:                postgres
      KONG_NGINX_WORKER_PROCESSES:  1
      KONG_PG_DATABASE:             kong
      KONG_PG_PASSWORD:             <set to the key 'postgresql-password' in secret 'apigw-postgresql'>  Optional: false
      KONG_PG_USER:                 kong
      KONG_PORTAL_API_ACCESS_LOG:   /dev/stdout
      KONG_PORTAL_API_ERROR_LOG:    /dev/stderr
      KONG_PROXY_ACCESS_LOG:        /dev/stdout
      KONG_PROXY_ERROR_LOG:         /dev/stderr
    Mounts:
      /kong from custom-nginx-template-volume (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-77fvd (ro)

I guess the script is stuck:
until kong start; do echo 'waiting for db'; sleep 1; done; kong stop

I've test on two k8s cluster. one is normal start, the other failed.
helm script:
helm install --name sqldb \
--namespace kong \
--set image.tag=12.1.0 \
--set image.pullPolicy=IfNotPresent \
--set postgresqlDatabase=kong \
--set postgresqlUsername=kong \
--set postgresqlPassword=kong \
--set persistence.enabled=false \
stable/postgresql

helm install --name apigw \
--namespace kong \
--set image.tag=1.4 \
--set env.database=postgres \
--set env.pg_host=sqldb-postgresql \
--set env.pg_database=kong \
--set env.pg_user=kong \
--set env.pg_password=kong \
--set admin.useTLS=false \
--set readinessProbe.httpGet.scheme=HTTP \
--set livenessProbe.httpGet.scheme=HTTP \
stable/kong

check the job logs:
kubectl logs -f  job/apigw-kong-init-migrations
Bootstrapping database...
Error: [PostgreSQL error] cluster_mutex callback threw an error: /usr/local/share/lua/5.1/kong/cmd/utils/migrations.lua:56: [PostgreSQL error] failed to run migration '000_base' up: receive_message: failed to get type: timeout
stack traceback:
	[C]: in function 'assert'
	/usr/local/share/lua/5.1/kong/cmd/utils/migrations.lua:56: in function </usr/local/share/lua/5.1/kong/cmd/utils/migrations.lua:55>
	[C]: in function 'xpcall'
	/usr/local/share/lua/5.1/kong/db/init.lua:358: in function </usr/local/share/lua/5.1/kong/db/init.lua:308>
	[C]: in function 'pcall'
	/usr/local/share/lua/5.1/kong/concurrency.lua:45: in function 'cluster_mutex'
	/usr/local/share/lua/5.1/kong/cmd/utils/migrations.lua:55: in function 'bootstrap'
	/usr/local/share/lua/5.1/kong/cmd/migrations.lua:181: in function 'cmd_exec'
	/usr/local/share/lua/5.1/kong/cmd/init.lua:87: in function </usr/local/share/lua/5.1/kong/cmd/init.lua:87>
	[C]: in function 'xpcall'
	/usr/local/share/lua/5.1/kong/cmd/init.lua:87: in function </usr/local/share/lua/5.1/kong/cmd/init.lua:44>
	/usr/local/bin/kong:9: in function 'file_gen'
	init_worker_by_lua:47: in function <init_worker_by_lua:45>
	[C]: in function 'xpcall'
	init_worker_by_lua:54: in function <init_worker_by_lua:52>

  Run with --v (verbose) or --vv (debug) for more details
migrating core on database 'kong'...
rpc error: code = Unknown desc = Error: No such container: 738e002526bc47c73f98ea5295920747fb985c1c32da4ab7af078e9b790c559d

The normal one logs:
Bootstrapping database...
migrating core on database 'kong'...
core migrated up to: 000_base (executed)
core migrated up to: 001_14_to_15 (executed)
core migrated up to: 002_15_to_1 (executed)
core migrated up to: 003_100_to_110 (executed)
core migrated up to: 004_110_to_120 (executed)
core migrated up to: 005_120_to_130 (executed)
core migrated up to: 006_130_to_140 (executed)
migrating hmac-auth on database 'kong'...
hmac-auth migrated up to: 000_base_hmac_auth (executed)
hmac-auth migrated up to: 001_14_to_15 (executed)
hmac-auth migrated up to: 002_130_to_140 (executed)
migrating oauth2 on database 'kong'...
oauth2 migrated up to: 000_base_oauth2 (executed)
oauth2 migrated up to: 001_14_to_15 (executed)
oauth2 migrated up to: 002_15_to_10 (executed)
oauth2 migrated up to: 003_130_to_140 (executed)
migrating jwt on database 'kong'...
jwt migrated up to: 000_base_jwt (executed)
jwt migrated up to: 001_14_to_15 (executed)
jwt migrated up to: 002_130_to_140 (executed)
migrating basic-auth on database 'kong'...
basic-auth migrated up to: 000_base_basic_auth (executed)
basic-auth migrated up to: 001_14_to_15 (executed)
basic-auth migrated up to: 002_130_to_140 (executed)
migrating key-auth on database 'kong'...
key-auth migrated up to: 000_base_key_auth (executed)
key-auth migrated up to: 001_14_to_15 (executed)
key-auth migrated up to: 002_130_to_140 (executed)
migrating rate-limiting on database 'kong'...
rate-limiting migrated up to: 000_base_rate_limiting (executed)
rate-limiting migrated up to: 001_14_to_15 (executed)
rate-limiting migrated up to: 002_15_to_10 (executed)
rate-limiting migrated up to: 003_10_to_112 (executed)
migrating acl on database 'kong'...
acl migrated up to: 000_base_acl (executed)
acl migrated up to: 001_14_to_15 (executed)
acl migrated up to: 002_130_to_140 (executed)
migrating response-ratelimiting on database 'kong'...
response-ratelimiting migrated up to: 000_base_response_rate_limiting (executed)
response-ratelimiting migrated up to: 001_14_to_15 (executed)
response-ratelimiting migrated up to: 002_15_to_10 (executed)
migrating session on database 'kong'...
session migrated up to: 000_base_session (executed)
34 migrations processed
34 executed
Database is up-to-date

sorry, my  network problem.

A couple of FAQs have been added to the readme of Kong's chart. Please go through the recommended steps there to solve this issue.

As this issue is related to start Kong with a fresh Postgress, I follow the FAQ Kong fails to start on a fresh installation with Postgres. What do I do?. However, I still have the same problem with my-kong-kong-init-migrations pod.
$ minikube start --memory='8000mb' --vm-driver='virtualbox'

$ kubectl create namespace dev
namespace/dev created

$ kubectl get pv -n dev
No resources found in dev namespace.

$ helm install my-kong \
--namespace dev \
--set image.tag=1.4.0 \
--set postgresql.enabled=true \
--set env.database=postgres \
--set admin.useTLS=false \
--set readinessProbe.httpGet.scheme=HTTP \
--set livenessProbe.httpGet.scheme=HTTP \
stable/kong

$ kubectl get pods -n dev --watch
NAME                                 READY   STATUS     RESTARTS   AGE
my-kong-kong-78dd884b77-246ws        0/2     Init:0/1   0          19s
my-kong-kong-init-migrations-qnt56   0/1     Init:0/1   0          19s
my-kong-postgresql-0                 0/1     Init:0/1   0          19s
my-kong-kong-78dd884b77-246ws        0/2     Init:0/1   0          19s
my-kong-postgresql-0                 0/1     PodInitializing   0          25s
my-kong-postgresql-0                 0/1     Running           0          42s
my-kong-postgresql-0                 1/1     Running           0          47s
my-kong-kong-init-migrations-qnt56   0/1     PodInitializing   0          50s
my-kong-kong-init-migrations-qnt56   0/1     Error             0          51s
my-kong-kong-init-migrations-qnt56   0/1     Error             1          52s
my-kong-kong-init-migrations-qnt56   0/1     CrashLoopBackOff   1          66s
my-kong-kong-init-migrations-qnt56   0/1     Error              2          66s
my-kong-kong-init-migrations-qnt56   0/1     CrashLoopBackOff   2          80s

Can you share the logs of the init migration container that is failing?


Will ActiveJDBC pass all Turkey Tests?

Turkish people write July 4th, 2008 as "04.07.2008"
Turkish people use a period to group digits
The "I" in Turkish behaves differently than in most languages when converted to upper or lower case (this is the hardest one, as we use lots of toUpperCase() and toLowerCase())
Mind Arabic digits

References

http://www.moserware.com/2008/02/does-your-code-pass-turkey-test.html
http://blog.codinghorror.com/whats-wrong-with-turkey/

@ericbn have a feeling we will fail this test completely :)


[FEA] Default executorEnv for UCX

There are at least two boilerplate settings that need to be set for UCX: disabling signal catching, and disabling the memtype cache (though in later versions of UCX the second one here is default off). There are more settings, especially for the wakeup protocol (i.e. we memory mapped IO within a machine has been shown to cause hangs, when used in conjunction with wakeup).
When we launch JUCX it is too late for it to change these settings and it would require bigger changes in UCX to make it happen. Instead, I was thinking of potentially mutating executorEnv (which looks to be private[spark] right now in SparkContext).
This issue is to figure out if we can mutate executorEnv in every environment (i.e. it works in Standalone, but @tgravescs pointed out that Yarn client-mode may not).
If this does work, at least for the majority of environments users will be working under, I think it may be sensible to add the code. Additionally, a Spark issue could be filed for the cases where it doesn't.

Preference is to put up a SPIP for Spark plugins to modify the executorEnv if so desired.
@tgravescs is this something that is worth pursuing without going the SPIP route first?

yes I think we should prototype and see how much changes. If its minor change to the plugin api which is developer api shouldn't need a spip


Admin Configuration

Hello, just felt it would be better opening an issue here.
So on performing my own internal configurations, I came across this.

All the requirements have been downloaded and installed. What am i doing wrong

Hello again, sorry for the lack of updates,
I have gone through all the configuration, currently my server is still a shared hosting account and my webhost said I must engage in a VPS before I can utilize react.js or node.js

@thefrancisugorji
Pls share the admin backend code as am abit good with react maybe i could be of help here
email<EMAIL_ADDRESS>@o1298098
Nice job Boss.....This is a very good project
you really aiding my learning curves
I noticed this talkings about external stream links which i have no idea off
could you pls share me to the admin table...
email<EMAIL_ADDRESS>really needing some practical stuffs + How can i contact your DM ?


Environment.OSVersion.Platform always showing as Unix

It looks like from my testing that the Platform is always showing as Unix, even when working on a IIS Express in windows. Could very well be from Mono, but wondering if it is by design, a bug or a future enhancement.

Platform is irrelevant. You are in browser sandbox that is aleady abstraction above some platform. As far I know WASM is aiming to be close to Unix platform in terms of its sandbox so probably that is the reason.

I understand your statement that Platform is irrelevant in a traditional browser sandbox context, but isn't WebAssembly changing that concept? Given that, in a WebAssembly, the client (browser) has the ability to run .NET code, why would .NET functionality allowed to be restricted to only PlatformId.Unix? (ex: AssemblyBuilder.DefineDynamicAssembly, and many others).

@rlmartins76 like @arkadiuszwojcik said it's a sandbox (OS is hidden) you can't do anything Windows specific in it. Same restrictions that apply to JavaScript apply here. You can't do anything Windows specific in browser with JavaScript as well. If you could, that would be a huge security risk.


exp/logging-messages-style

Description
Hi all!
I noticed that the logging output levels are currently left-aligned with a width of 21 characters. Is there any specific reason for this?
Here's an example of the current formatting:

While it's not a major issue, I believe removing the white spaces could improve the visualization.
In this PR, I've adjusted the formatting accordingly and included a new test to validate the output format, specifically for error and warning messages:

Another option could be centering the text and reducing the total width slightly...
Perhaps in the future, we could explore using colors to differentiate between different log levels.

Related Issues
Nope

Thanks!

@cacrespo heh good point :) I took this formatter from my older projects when we started writing dlt. the intention was to align all log lines where file name and line number where... but since that time we added more things and that does not make sense.
btw. log format is configurable via toml files and env variables (RUNTIME__LOG_FORMAT). so if you want colors you can add them (but no variable colors without changing code I'm afraid)
I'm ok with merging this. @burnash @sh-rp WDYT?

Hi there!
I've just reviewed the tests and found something odd. If you run test_logging.py before test/common/runners, everything works fine. However, if you execute the logging tests after the runners, we encounter problems (as is happening now).
The conflicts are particularly with these tests:
@pytest.fixture(scope="module", autouse=True)
def logger_autouse() -> None:
    init_test_logging()

@pytest.mark.parametrize("method", ALL_METHODS)
def test_pool_runner_process_methods_forced(method) -> None:
    multiprocessing.set_start_method(method, force=True)
    r = _TestRunnableWorker(4)
    # make sure signals and logging is initialized
    C = resolve_configuration(RunConfiguration())
    initialize_runtime(C)

    runs_count = runner.run_pool(configure(ProcessPoolConfiguration), r)
    assert runs_count == 1
    assert [v[0] for v in r.rv] == list(range(4))

@pytest.mark.parametrize("method", ALL_METHODS)
def test_pool_runner_process_methods_configured(method) -> None:
    r = _TestRunnableWorker(4)
    # make sure signals and logging is initialized
    C = resolve_configuration(RunConfiguration())
    initialize_runtime(C)

    runs_count = runner.run_pool(ProcessPoolConfiguration(start_method=method), r)
    assert runs_count == 1
    assert [v[0] for v in r.rv] == list(range(4))

My conclusion is that we have some problem happening when the process instantiates the configuration through the different tests.
Honestly, I don't know enough about pytest, but I made some changes (see the last commit), and now it seems that the problems are resolved (at least in my local environment).
Whatever you need, I'm here to help! 😃

@cacrespo OK! let me check it. runner will initialize logging on their own and we do not have a proper way to "uninitialize" them. So some settings may not be applied. I'm running CI again and the see which tests are failing. thx!

@cacrespo You can change the logging format via your config.toml if you like by the way.

@cacrespo You can change the logging format via your config.toml if you like by the way.

Yes, you're right. I think it's the best option instead of trying to change the application logger. 😜
For your information, I used pytest-randomly and I believe there are some flaky tests (apart from my problem). Here are my steps and an example:
Add the package:
poetry add pytest-randomly

Run the tests without randomness:
poetry run pytest -p no:randomly tests/common/runners tests/common/runtime

Everything goes fine.
Run the tests with randomness:
poetry run pytest --randomly-seed=1330321047 tests/common/runners tests/common/runtime

We encounter some errors.
Hope this helps improve this great tool. Thanks!

@cacrespo I have created a new branch (since this one is yours) with only the change you suggested: https://github.com/dlt-hub/dlt/pull/1517. I'm happy to attribute it to you, I don't think we need any tests for this at the moment.

Closed by #1517


[UI] - RTK Migration Designs

Notes for Reviewers
This PR fixes #10046 and related #9985
@senali-d @sudhanshutech

[X] publish design

api/pattern/catalog/publish [POST] -> https://docs.meshery.io/reference/rest-apis#api-pattern-catalog-publish

[X] Unpublish design

api/pattern/catalog/unpublish [DELETE] -> https://docs.meshery.io/reference/rest-apis#api-pattern-catalog-unpublish

[X] Deploy design

api/pattern/deploy [POST] -> https://docs.meshery.io/reference/rest-apis#api-pattern-deploy

[X] Undeploy design

api/pattern/deploy [DELETE] -> https://docs.meshery.io/reference/rest-apis#api-pattern-deploy

I left a note for the deploy and undeploy calls since i had to hardcode the /api/pattern/deploy because I was getting an extra /api prefixed through ctxUrl for some reason. This behavior didn't happen in the original dataFetch implementation so I suspect rtk-query might be to blame here but I'm not sure.
I also opened up this second PR and will close the first one since I ran into multiple git rebase problems since I missed signing off one commit.
Signed commits

[X] Yes, I signed my commits.

@cesartheroman one more thing can you confirm is that when i unpublished a design the ui is not updating most probably with publishing also, you can use refetch property of rtk here

@cesartheroman i am seeing double notifications for same thing while publishing and unpublishing both. for example:  though the blue one should be only there but since its a success it should be green

@sudhanshutech this issue is not related to this PR, we can iterate over this

@cesartheroman ready to role here?

Do not close yet.


xcaddy v0.3.5 vs v0.4.0 = 15mb increase in filesize on windows

What caused such huge amount of increased file size, I'm mean caddy is already beautiful small in size for what it can achieve.
But was just wondering..

Is this the exact same version of Caddy and Go? (What is the output of caddy build-info for both binaries?) The only difference is the version of xcaddy used to build it?

For the record, the size of the CI artifact of Caddy at commit https://github.com/caddyserver/caddy/commit/7e2510ef43d3439c682d56b580e4013a0cc9cc3e is 41.1MB. I doubt the xcaddy version changes anything, unless you're using the --embed feature. But, yes, we need more details.

Is this the exact same version of Caddy and Go? (What is the output of caddy build-info for both binaries?) The only difference is the version of xcaddy used to build it?

For the record, the size of the CI artifact of Caddy at commit caddyserver/caddy@7e2510e is 41.1MB. I doubt the xcaddy version changes anything, unless you're using the --embed feature. But, yes, we need more details.

Both version

How can we reproduce the size difference?

I see a difference here

also I see -trimpath=true  cmd missing in 0.4.0 and replaced on same line with -tags=nobadger,

Ah! Of course. :) Thanks for the quick fix!

Found the culprit. I added this line here:
https://github.com/caddyserver/xcaddy/blob/f99151eee93013f77053d29c62e9da4ad3eb5738/environment.go#L130
which tripped this check here:
https://github.com/caddyserver/xcaddy/blob/f99151eee93013f77053d29c62e9da4ad3eb5738/builder.go#L130-L135
so now debug symbols are not removed and the paths are not trimmed.
One sec...

hotfix issue
https://github.com/caddyserver/xcaddy/actions/runs/8971616569?pr=182
2024/05/06 17:27:13 [INFO] exec (timeout=0s): C:\Program Files\Go\bin\go.exe mod tidy -e
2024/05/06 17:27:14 [INFO] exec (timeout=0s): C:\Program Files\Go\bin\go.exe build -o C:\Users\Denni\Desktop\xcaddy\caddy.exe -ldflags -w -s -trimpath -tags nobadger
flag provided but not defined: -tags nobadger
usage: go build [-o output] [build flags] [packages]
Run 'go help build' for details.
2024/05/06 17:27:15 [INFO] Cleaning up temporary folder: C:\Users\Denni\AppData\Local\Temp\buildenv_2024-05-06-1726.2852208866
2024/05/06 17:27:15 [FATAL] exit status 2


creating patches is taking forever long

for more than 7 hours it stays on searching for patch 0 for only 4 patient's slices PNG(Training_PNG data is low) still it has not completed. Ct variable is not changing.

did you solved it?


Divider below title

Hi, I'm using library for my Alert Dialog in my app. Everything is fine for me but divider. I want a divider below title and icon. Can we do this? Is it possible? Please help me

You can use a custom layout for that purpose. For example you can use following piece for assigning a custom layout to your dialog. On your custom dialog simply create your needs as usual.
final MaterialDialog.Builder builder = new MaterialDialog.Builder(ctx);         builder.customView(layoutID, false);
If you want to reach out your custom views afterwards, you can directly use dialog itself to reach views as follows:
Button yourButton = (Button) yourDialog.getView().findViewById(R.id.yourButton);

Ok Thank You. I will try customview.


fix valset file names

these two file names seem to be switched:

query_get_current_validator_set_timestamp.go
query_get_validator_set_index_by_timestamp.go

fix them

fixed


Modified prompt format.

Overview:
Modified the prompt format to be more condensed and use the chat completions system role.
Some testing should probably be done to find the 'best' results.
References:

https://platform.openai.com/docs/guides/completion/prompt-design
https://platform.openai.com/docs/guides/chat

Merged locally.


Placing ion-select inside a  causes select to trigger regardless of where user clicks

Short description of the problem:
When an ion-select is placed inside a table, it will prompt the user to select, regardless of where the user clicks in the screen.  This behavior has only been observed in a webpage.
What behavior are you expecting?
Select should prompt user only when the control is clicked on.
Steps to reproduce:

Click on controls, all prompts should work as selected.
To cause to fail, select the checkbox in the upper right.  This will add an  to the table.
Now regardless of where the user clicks, the select will appear.

Ionic Version: 2.x
Plunker that shows an example of issue
Ionic 2 plnkr - http://plnkr.co/edit/wSGoGo?p=preview

Hello, thanks for opening an issue with us! So the issue here is that ion-select is meant to be wrapped in ion-item because it needs a relatively positioned parent. I made a plunker that shows the correct way to do this here Thanks for using Ionic!

Thank you.

On Jul 7, 2016, at 3:13 PM, Justin Willis<EMAIL_ADDRESS>wrote:
Hello, thanks for opening an issue with us! So the issue here is that ion-select is meant to be wrapped in ion-item because it needs a relatively positioned parent. I made a plunker that shows the correct way to do this here Thanks for using Ionic!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Is this in the documentation anywhere?


Links and buttons updates

Updates to How To Test Links and Buttons:

Used a div button instead of negative tabindex as non-focusable example
Updated disabled button example to look disabled but still be actionable
updated the last ("current") breadcrumb link to be bold

@tritland Looks good to me but I think there are changes in this PR that are the same/similar to https://github.com/tmobile/magentaA11y/pull/75/files/8c272a7530b6e501372af9b8caef291cd34803ac#r1336191121 ? Don't want ya to run into any conflicts.


Fixed link text

This document talk about Hyper-V. Also, the link target is Hyper-V assessment.

@tksh164 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Looks good. @tksh164 Thanks for this fix.


notifies agent when assigned to a private ticket

An enhancement for #435
notifies agent when assigned to a private ticket

This feature is nicely done!
However, Admin::TopicsController#assign_agent uses Topic#bulk_assign, which in turn uses update_all, which doesn't trigger callbacks, meaning that the after_save callback you are using to detect the change in an assigned user is never fired.
A fix might be to change Topic#bulk_assign to iterate over the given topics, and call update on each individually.
Although I'm not sure what @scott thinks about this.

Yeah the reason we went to update_all was to speed up the operation.  See notes in https://github.com/helpyio/helpy/pull/238  I think the solution might be that bulk assignments don't trigger a notification, or we may have to come up with some other way to do it?

We could just change the notification to be triggered within the TopicsController#assign_agent.
Essentially we would pass @topics, and assigned_user to NotificationMailer#ticket_assigned  able to handle multiple topics.

Yeah @CGA1123 , I think I flow with that line of thought as well, because basically, when there is a bulk assign like this, the assignee is the same person, and I think it will be cool to send the assignee a single notification for all the topics as opposed to individual notification for each
So, I think modifying NotificationMailer#ticket_assigned to handle both single and multiple topics, and then calling it from the TopicsController#assign_agent as well as leaving it in the callback for single updates can work well.

@CGA1123 @scott I made updates to this PR to handle the bulk_assignment... is there some other enhancements that you'll like to suggest in addition to this?

Seems to look good on first glance.
Although, I feel like it may be better to add proper detail about which topics a user has been assigned to, rather than saying "and some others".
You could loop over @bulk to give the topic name and a link.
This would also remove the need to check whether more than 1 topic has been assigned, instead you could just put You have recently been assigned to the following topic(s): and then loop over @bulk as described above.

Great, thanks @CGA1123
I implemented that now... looping through bulk_messages and listing their names in a ordered list, with a link to View each topic assigned.

@SundayAdefila Looking good, just a couple of small things that could improve this, which I've outlined in the review.

Hey @CGA1123 @scott Happy new year guys... Any new update on this?


Fix issue where table field IDs get quoted if field name contains special chars

#293 caused a side-effect where the ID of table fields would sometimes get wrapped in double quotes.
This change makes it so that only the relevant AddPrefixAndSuffix methods get called for the object type. For example, the logic to fix page fields will not get called on table objects or tableextension objects.

I was also fixing this - another way - but this seems pretty much the same.  So there will be a double check, I guess🤷♂😉


Attach gzipped dylib as part of publishing

Adds attaching javy-quickjs_provider-${{ javy_version }}.wasm.gz and its sha to releases.
This seems like a reasonable way to start publishing a dylib to use though it does tie Javy and javy_quickjs_provider versions together.
The name format is somewhat arbitrary and I'm okay with changing it if it makes sense. But I figured the .wasm extension should be enough of a hint about what architecture it's targeting to not need to include wasm32-wasi in the name.

I'm going to hold off on this until we get the Wizer story for the provider figured out


Grids of cards not rendering

Grids of cards not rendering.
Steps to reproduce:

Copy the grid of cards example  and put the copied content in any file structured within _toc.yaml.
Install sphinx-design with pip install sphinx-design or poetry add sphinx-design
Insert the content below into _config.yaml:

sphinx:
  extra_extensions:
  - sphinx_design

When I build my book, this is rendered as pure text.

@HenriqueAJNB Hey! Have you found a solution?

Hey @HenriqueAJNB,
I figured out what was causing the issue on my end. At some point, I added the myst-extension for deflist to my _config.yml, and it turns out that this disables all the default extensions. To fix it, I just re-added the extension for colon_fence, and that solved the problem.
It might help you too! Here’s how my myst_enable_extensions section in _config.yml looks now:
parse:
  myst_enable_extensions:
    # Make sure to include any other extensions you need,
    # even those that are enabled by default!
    - deflist
    - colon_fence

Hope that helps!
Best,
Vladimir


Querying JSON-type columns that are arrays at the top level doesn't work with dot notation.

We are using Pinot 0.8.0 and have a JSON-type column with a JsonIndex on it. The top-level of the JSON is an array, and from https://docs.pinot.apache.org/users/user-guide-query/json-queries, it seems like we should be able to query it like
select feedback_issues_json[0] from test_table limit 10

select feedback_issues_json[0].value from test_table limit 10

but this doesn't return any rows. From the broker response it seems like feedback_issues_json[0] is being interpreted as the column name.
cc: @Jackie-Jiang

@amrishlal Could you please take a look?

I have created a PR to fix this issue. Please see #7511. Also, it seems like a similar fix is needed in JsonIndex / JSON_MATCH as well to allow for running queries such as:
SELECT *
  FROM testTable
WHERE JSON_MATCH(jsonColumn, '\"$.[2]\" IS NOT NULL') AND JSON_MATCH(jsonColumn, '\"$.[2]\" = ''test''')

I am assuming that you can take a look at JsonIndex / JSON_MATCH changes?

@amrishlal Thanks for working on this issue
The JSON_MATCH should already support it, and the correct syntax is JSON_MATCH(jsonColumn, '"$[2]" IS NOT NULL') (No escape for double quote & no . for array access)


Application Error

Please send your build & application logs depending on how far you got
as well as your method of deployment. (button, fork, heroku cli)

2022-02-09T01:18:32.736216+00:00 heroku[web.1]: Process exited with status 127
2022-02-09T01:18:32.798490+00:00 heroku[web.1]: State changed from starting to crashed
2022-02-09T01:20:34.531887+00:00 app[api]: Starting process with command java jar lavalink.jar by user abel
2022-02-09T01:20:38.689836+00:00 heroku[run.2057]: State changed from starting to up
2022-02-09T01:20:38.910796+00:00 heroku[run.2057]: Awaiting client
2022-02-09T01:20:38.938027+00:00 heroku[run.2057]: Starting process with command java jar lavalink.jar
2022-02-09T01:20:43.006530+00:00 heroku[run.2057]: Process exited with status 1
2022-02-09T01:20:43.127744+00:00 heroku[run.2057]: State changed from up to complete
2022-02-09T01:21:55.084040+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/" host=abel-lava.herokuapp.com request_id=11b8f593-e542-432d-ace8-1cab66199960 fwd="<IP_ADDRESS>" dyno= connect= service= status=503 bytes= protocol=https
2022-02-09T01:21:55.478413+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/favicon.ico" host=abel-lava.herokuapp.com request_id=c55812b5-b699-4f8a-85d9-a6fd28227fac fwd="<IP_ADDRESS>" dyno= connect= service= status=503 bytes= protocol=https

method is fork

It seems like the nodejs buildpack was not automatically added.
You can manually add it by going to your project settings on heroku, scroll down to buildpacks, and add heroku/nodejs.
While you're there, if heroku/java is not added you should add it.

It seems like the nodejs buildpack was not automatically added.
You can manually add it by going to your project settings on heroku, scroll down to buildpacks, and add heroku/nodejs. While you're there, if heroku/java is not added you should add it.

where to find my port?

The port you use to connect to heroku will be 80 (or 443 if you're using SSL).
After adding the buildpacks, you should redeploy.
Furthermore, I recommend just using the One Click Deploy button.

The port you use to connect to your lavalink server on heroku will be 80 (or 443 if you're using SSL). After adding the buildpacks, you should redeploy.
Furthermore, I recommend just using the One Click Deploy button.

port 80 not working


Create on-the-fly index column if you don't explicitly specify one

I wonder if you could point me to a starting point, how to implement this and if there are any caveats to think of.
Problem: I generate csv files from a database view and they don't have a unique identifier which could be used as index.
Idea: use the line number of the current row - 1 as index. (like adding a virtual colum in the csv)
With the current implementation this use-case will fail silently, as no changes are reported:
from csvdiff import *
diff_files("e.txt", "f.txt", [], ";")
I would like to implement this functionality and provide a pull request for this feature if you think that is a good idea.
e.txt
f.txt
I had to rename the files to .txt as github doesn't support .csv

I have the same problem. Did you resolve this problem?
I would like to compare two different csv. but unfortunately, csvdiff can't find all the line which are changed.

@karakutu001 No, I needed a quick fix and it I just prefixed my data files with a "rowID" column and used that. But you are more than welcome to provide some code. I am busy right now, but I could help with it in the next weeks.


python3Packages.wat: 0.1.2 -> 0.3.0 and python3Packages.nuclear: 2.2.5 -> 2.3.1

Description of changes
Update wat and nuclear together, since nuclear is the key dependency of wat.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@ofborg build python311Packages.wat python312Packages.wat