text:
Require a token for all API endpoints

Overview
Adds an authentication requirement to all API endpoints.

Required for accurately reporting on API usage.
Allows for disabling accounts that accidentally or maliciously overuse the APIs.

Maintains the ability for the web application to make API requests on behalf of unauthenticated users.
Connects #636
Demo

Notes
I have added an OAR_CLIENT_KEY to the staging tfvars file. There is a checklist item on this PR to make sure the next release issue includes updating the production tfvars file.
Testing Instructions
Setup

./scripts/manage resetdb
./scripts/manage loadfixtures
./scripts/manage processfixtures

Enable Rollbar in development

Set the ROLLBAR_SERVER_SIDE_ACCESS_TOKEN value in .env.backend
Enable Rollbar in settings.py

diff --git a/src/django/oar/settings.py b/src/django/oar/settings.py
index 10c2f02..bb0a11e 100644
--- a/src/django/oar/settings.py
+++ b/src/django/oar/settings.py
@@ -338,7 +338,7 @@ if GOOGLE_SERVER_SIDE_API_KEY is None:
     raise ImproperlyConfigured(
         'Invalid GOOGLE_SERVER_SIDE_API_KEY provided, must be set')

-if not DEBUG:
+if True:
     ROLLBAR = {
         'access_token': os.getenv('ROLLBAR_SERVER_SIDE_ACCESS_TOKEN'),
         'environment': ENVIRONMENT.lower(),

Test

Start ./scripts/server.
Ensure that you are not logged in to the application
Verify that you can use the application as normal.
Verify that curl http://localhost:6543/api/countries/ returns a response.
Set an OAR_CLIENT_KEY env var in docker-compose.yml and restart ./scripts/server

diff --git a/docker-compose.yml b/docker-compose.yml
index a769732..1f477a4 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -25,7 +25,7 @@ services:
         - DJANGO_SECRET_KEY=secret
         - DJANGO_LOG_LEVEL=INFO
         - AWS_PROFILE=${AWS_PROFILE:-open-apparel-registry}
-        - OAR_CLIENT_KEY=
+        - OAR_CLIENT_KEY=clientkey
     build:
       context: ./src/django
       dockerfile: Dockerfile

Verify that you can still use the application as normal.
Verify that curl http://localhost:6543/api/countries/ now returns an error message and that an "Incorrect client key submitted with API request" occurrence is logged to Rollbar

{"detail":"Authentication credentials were not provided."}

Make a request with a client key header

curl \
  -H "X-OAR-Client-Key: clientkey" \
  http://localhost:6543/api/countries/

Verify that the same authentication error is returned, but an "Unallowed referring host passed with API request" warning is logged in Rollbar.
Make a request with a client key and a referrer

curl \
  -H "X-OAR-Client-Key: clientkey" \
  -H "Referer: http://localhost:6543" \
  http://localhost:6543/api/countries/

Verify that it is sucessful
Log in to the web app as c2@example.com.
Browse http://localhost:6543/profile/2 and generate an API token
Make an authenticated request with the token and verify that it succeeds.

curl \
  -H "Authorization: Token {{API-TOKEN}}" \
  http://localhost:6543/api/countries/

Checklist

[ ] fixup! commits have been squashed
[ ] CI passes after rebase
[ ] CHANGELOG.md updated with summary of features or fixes, following Keep a Changelog guidelines
[ ] Add a checklist item to the next release issue for adding an OAR_CLIENT_KEY to  the tfvars.

Temporarily closed to trigger a build and deploy of the test branch to staging.

Taking a look now

This broke AWS Batch jobs on staging because the new OAR_CLIENT_KEY environment variable is not set correctly. I'll be pushing a fix, but it will likely just be a fix to the provisioning.

Temporarily closing to trigger a new build and deploy.

Rollbar logs warnings for "incorrect client key" and "unallowed referring host", but not for "invalid token"

This is by design. This new client key system is wholly separate from token-based authentication. Passing the wrong token is just like entering the wrong password, and we are currently not doing any special logging for failed authentication.
RE: The Rollbar re-init warning thanks for mentioning it. It was worth doing a little reading to understand what is going on. This PR sums up our situation and why it is expected.
https://github.com/rollbar/pyrollbar/pull/198

This is annoying in configurations where init() is expected
to be called twice. One such configuration is a Django project where the
rollbar middleware is installed (which calls rollbar.init() internally),
but the project also needs to be able to run without the middleware (from
headless scripts, etc.)

I will take advantage of the feature added in that PR and suppress the innocuous warning.

Thanks for the thoughtful review.

authors: jwalgran rajadain


text:
Set up cron job

[ ] Update script to be run daily
[ ] Set up cron job on Azure VM (or something)
[ ] Add geocoding to daily script

i'll take a stab at adding geocoding to the script

hey, good job.

hey, thanks.

source: gharchive/issue

authors: luqmaan spatialaustin

repo: open-austin/construction-permits

license: unlicense

license_type: permissive

license_source: bigquery


text:
Add Contributing section to README.md

Now that the CONTRIBUTING.md doc is in place, I think the README.md should:

[ ] link to the CONTRIBUTING.md
[ ] Title
[ ] Tiny introduction/description that describes something regarding contributing

overtaken by events

authors: lianilychee techtolentino

license: Unlicense

license_source: github-api


text:
:book: Update readme with addon contributions link

Summary
Update the README with addon contribution repo link
Related issue(s)
Fixes #

Doc update like this one should not trigger e2e.
Did I not do something in the PR?

Doc update like this one should not trigger e2e. Did I not do something in the PR?

No, I met the same e2e which should not occur, it seems like some thiing addon-framework e2e depends on changed, for example the images it use or the clusteradmin.

Doc update like this one should not trigger e2e. Did I not do something in the PR?

No, I met the same e2e which should not occur, it seems like some thiing addon-framework e2e depends on changed, for example the images it use or the clusteradmin.

Thanks and go to sleep :sweat_smile:

/lgtm

/approve

source: gharchive/pull-request

authors: mikeshng xuezhaojun zhujian7


text:
Update README.md

Add some mandatory pre-steps before building the docker image

/assign @elgnay

@kim-fitness
please avoid adding your local binaries in the PR.

Thanks, please squash the commit and signoff.

btw, I would suggest to add _output into .gitignore.

@kim-fitness
please avoid adding your local binaries in the PR.

Oops, that's my fault, let me reset this commit then, thanks for the heads-up!

Since the modification of file .gitignore is not related with the original issue, I'll leave it as a separate commit.
If it is not the practice of this project, please let me know and squash them up then. Thanks.

that is fine, would you squash this to one commit and we are good to go.

/approve
/lgtm

authors: kim-fitness qiujian16 xunpan

repo: open-cluster-management-io/placement


text:
Do not attempt the scale tests

Signed off by @jnpacker

Sonar to skip controller_test.go which is a scale test and requires an endpoint

/lgtm

/lgtm

authors: hanqiuzh jnpacker


text:
bug fix - do not copy finalizers from user namespace to MC namespaces

fix a bug of copying finalizers from user namespace to clusters namespaces.
finalizer has to be removed to avoid having the policy stuck forever on the MCs.
Signed-off-by: Nir Rozenbaum nirro@il.ibm.com

/assign @ycao56

as part of our work with ACM far edge squad we’re working a lot with policies.
I’ve found a minor bug I want to fix. let me describe it quickly:
a user creates a new policy in his user namespace (with placement rule and binding).
now let’s assume from some reason the user decided to put finalizer on his policy since he needs to do some cleanup before the policy will be deleted.
the bug:
the finalizer will be replicated to managed clusters namespaces, and will also be replicated to the managed clusters themselves.
this will cause the policy not to be deleted on the MCs ever.
the fix to the bug -
when replicating the policy from user namespace to clusters namespaces, we need to clean finalizers, same as you clean other fields.


text:
upgrade clusterinfo crd

Signed-off-by: Zhiwei Yin zyin@redhat.com
story: https://github.com/open-cluster-management/backlog/issues/11698

/lgtm

repo: open-cluster-management/hub-crds


text:
Are images compressed in tsv files?

Thanks for your contribution to providing a collection of VLM datasets and models. I'm wondering why the tsv versions of datasets in this repository are smaller than the official versions. For example, the RealworldQA dataset downloaded from the official website RealWorldQA has 677MB, while the tsv version in this repo RealWorldQA_tsv only has 175MB. You are using base64 to encode images into texts and store them directly in tsv columns, which should be lossless. So why has the data size been reduced significantly? It seems that other datasets are having the similar situation.

Hello, @ywwynm
The images in the dataset on the official RealWorldQA website are in webp format, whereas when we converted the original dataset to tsv format, we uniformly converted it to JPEG format during encode, you can refer to the code here in our repo.

Thanks for your explanation. For other datasets like SeedBench or MMTBench, is such processing also performed? If the original images have already been in JPEG format, will you compress it again using the same code?

Hello, @ywwynm
In fact, if the original image is in jpeg format, there will not be such a significant change in data size even after our processing. We just convert it to the tsv format we need for the convenience of unified processing.

repo: open-compass/VLMEvalKit


text:
fix output typing, change mutable list to immutable tuple

Thanks for your contribution and we appreciate it a lot. The following instructions would make your pull request more healthy and more easily get feedback. If you do not understand some items, don't worry, just make the pull request and seek help from maintainers.
Motivation
Please describe the motivation of this PR and the goal you want to achieve through this PR.
Modification
Please briefly describe what modification is made in this PR.
BC-breaking (Optional)
Does the modification introduce changes that break the backward compatibility of the downstream repositories?
If so, please describe how it breaks the compatibility and how the downstream projects should modify their code to keep compatibility with this PR.
Use cases (Optional)
If this PR introduces a new feature, it is better to list some use cases here and update the documentation.
Checklist
Before PR:

[ ] Pre-commit or other linting tools are used to fix the potential lint issues.
[ ] Bug fixes are fully covered by unit tests, the case that causes the bug should be added in the unit tests.
[ ] The modification is covered by complete unit tests. If not, please add more unit test to ensure the correctness.
[ ] The documentation has been modified accordingly, like docstring or example tutorials.

After PR:

[ ] If the modification has potential influence on downstream or other related projects, this PR should be tested with those projects.
[ ] CLA has been signed and all committers have signed the CLA in this PR.

Thanks for your contribution, please check your PR with pre-commit hook.

authors: dmitrysarov tonysy

repo: open-compass/opencompass


text:
Conversion script: Improve the specificity of the location abbreviation lookups

Map abbreviated locations to full location tuples, which can then be used as precise inputs to the geocoder.
This allows us to (1) provide multiple-token abbreviations, and to (2) allow us to fully disambiguate a given abbreviation; previously, "GA" was mapped to "Georgia", but then "Georgia" itself is ambiguous; however, the tuple (None,'Georgia','United States') is unambiguous.
I also added a test for the geocoding util because WHY NOT

 Resolve errors in line-list data import

repo: open-covid-data/healthmap-gdo-temp

license: MIT


text:
My domain name requests

Description
Websites for a(some) company's I'm making
Link to Website
deenmaster.localplayer.dev (currently deenmaster.github.io)
eaglersky.localplayer.dev (currently eaglersky.github.io)
nasrstudios.localplayer.dev (currently codeless cause working on something else)
nasrgamingstudios.localplayer.dev  (also currently codeless cause working on something else)
this part of the code I didn't understand could you tell me how it works and fix it for me for next time (btw I currently dont have any dns's for the websites or any domains or anything)
{
"description": "Company Website",
"domain": "localplayer.dev",
"subdomain": "nasrstudios",
"owner": {
"repo": "https://github.com/Nasr-Studios-Inc/nasrstudios",
"email": "riyadbahabry@yahoo.com"
},
"record": {
"A": ["1.1.1.1", "1.0.0.1"],
"AAAA": ["::1", "::2"],
"CNAME": "example.com",
"MX": ["mx1.example.com", "mx2.example.com"],
"TXT": ["example_verification=1234567890"],
"CAA": [
{ "flags": 0, "tag": "issue", "value": "letsencrypt.org" },
{ "flags": 0, "tag": "issuewild", "value": "sectigo.com" }
],
"SRV": [
{ "priority": 10, "weight": 60, "port": 5060, "target": "sipserver.example.com" },
{ "priority": 20, "weight": 10, "port": 5061, "target": "sipbackup.example.com" }
]
},
"proxied": true
}

a bunch of buisness and stuff :)

btw the json is YOUR responsibility to fix, the team just does some cleanup, that's all.
also you have to sign the cla

i did but i dont have dns urls or anything of the sorts},
"record": {
"A": ["1.1.1.1", "1.0.0.1"],
"AAAA": ["::1", "::2"],
"CNAME": "example.com",
"MX": ["mx1.example.com", "mx2.example.com"],
"TXT": ["example_verification=1234567890"],
"CAA": [
{ "flags": 0, "tag": "issue", "value": "letsencrypt.org" },
{ "flags": 0, "tag": "issuewild", "value": "sectigo.com" }
],
"SRV": [
{ "priority": 10, "weight": 60, "port": 5060, "target": "sipserver.example.com" },
{ "priority": 20, "weight": 10, "port": 5061, "target": "sipbackup.example.com" }
]
},
"proxied": true
}if you could tell me how to set up this without having any of these features already set up i dont have a dns or a CAA or SRV or anything of the sorts cause i have no idea how they work if you could tell me how they work and how to fix it i will gladly fix it

np, i'll help you.
if you want to connect your domain to github pages (what you're using to host all your websites), you should add A records for:
185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153

you can search up your service provider on , they mostly likely have a guide for dns records.
then add your records to the json file. i'm assuming you know json here..you know json right?
you can  json, i'm not going to tell you how it works

also why did you modify terms.md, you just had to post ONE COMMENT here

does this work

yes. mostly. make it all lowercase

also list only one email

the lowercase part could you specify which part???

did I fix it???

hello I'm on break so please give me 1 1/2 month to complete this

You can re-open this PR when you come back by clicking the re-open button.

authors: DEV-DIBSTER bahabryra sctech-tr

repo: open-domains/register


text:
Handle thrown errors

I'd love it if errors my resolvers throw would get converted to rejected responses with a status code of 500. That way the app doesn't come crashing down if I hit something unexpected.

Makes sense. I'd treat such errors as 500, but without the X-Powered-By: "msw" header set to distinguish between mocked 500 response and library's error.
@kentcdodds, could you please describe what use case led to an error? That way I will make sure I account for all scenarios. Thanks.

I have some utilities I use in my resolvers. For these utilities it's just easier to throw an error (because we don't have access to the context):
throw new Error('username must be provided')

I realize that I'm missing the status code for this case and could probably make something work for that.
Also, there are sometimes regular runtime errors for things I haven't considered and it would be nice if the whole app didn't just crash when I hit those.

That's reasonable, thanks for sharing.
I find the safest way of error handling in this case to be the mockServiceWorker.js itself. That brings up the question of how to ensure that the installed library operates with the last Service Worker file (#81). Since the Service Worker is served by the application, it's possible to have an old file served, while the client-side code expects a different behavior from it.
I'm going to tackle Service Worker's integrity firsts, and introduce internal error handling as the next step. Meanwhile, I suppose you can handle such errors by doing this:
const { start } = composeMocks(/* your request handlers */)
start.catch(console.error)

This will not take into account any exceptions raised by mockServiceWorker.js, but rather cover the errors in the client-side library.

Hmmm.. But the error is thrown by the resolver which is called by the client-side code, not the service worker right?
—
Kent C. Dodds
--- original message ---
On March 24, 2020, 3:28 PM MDT notifications@github.com wrote:
That's reasonable, thanks for sharing.
I find the safest way of error handling in this case to be the mockServiceWorker.js itself. That brings up the question of how to ensure that the installed library operates with the last Service Worker file (#81). Since the Service Worker is served by the application, it's possible to have an old file served, while the client-side code expects a different behavior from it.
I'm going to tackle Service Worker's integrity firsts, and introduce internal error handling as the next step. Meanwhile, I suppose you can handle such errors by doing this:
const { start } = composeMocks(/* your request handlers */)
start.catch(console.error)

This will not take into account any exceptions raised by mockServiceWorker.js, but rather cover the errors in the client-side library.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
--- end of original message ---

@kettanaito, that's correct. The call stack overview looks as follows:
SW -- respondWith(pending Promise, (1)) -> match req on client side -> get response (2) -> resolve Promise

The error occurring in the resolver is inside the call stack of the Service Worker's respondWith (1), if it's handled on the Service Worker side it would act as the top-level safeguard for all errors within that stack. Is this a wrong presumption? 🤔

Oh, I see what you mean. Yes, that makes sense. I'm good with what you've suggested. Thanks!
—
Kent C. Dodds
--- original message ---
On March 24, 2020, 3:50 PM MDT notifications@github.com wrote:
@kettanaito, that's correct. The call stack overview looks as follows:
SW -- respondWith(pending Promise, (1)) -> match req on client side -> get response (2) -> resolve Promise
The error occurring in the resolver is inside the call stack of the Service Worker's respondWith (1), if it's handled on the Service Worker side it would act as the top-level safeguard for all errors within that stack. Is this a wrong presumption? 🤔
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
--- end of original message ---

Released in 0.12.0.
Please refer to the guide of mocking server errors in case your goal is to mock an error. I believe that introduced error handling is primarily useful for handling unintended exceptions inside request handlers, so they don't crash the application they are being used in. Similar to how you compose an error response in Express, I'd recommend to do so using the library's res() function.

authors: kentcdodds kettanaito

repo: open-draft/msw


text:
Expose a more general interface to commutator device functionality

We should refactor the TurnMotor operator to be either a CommutatorDevice or simply Commutator and expose a more general interface to the entire device functionality.
Detailed reasons below:

Formats a string. Expressions.Format seems like its fine for this already

While it is possible to format the JSON string with the Format operator, this locks us to a specific communication protocol. If we ever need to upgrade or extend the details of the JSON API in any way (or swap the protocol to binary, etc), we would not be able to easily upgrade old workflows. With the operator abstracting away the communication internals, we can get away with just upgrading the package, even for hand-crafted workflows.
I don't currently see any particular advantage of exposing the internal JSON strings, especially given the protocol does not comply to an existing standard and there is little cost or complexity added in doing this abstraction.

Toss ridiculous turn commands (NaN or inifnity). I guess a custom expression script would be needed to do this filtering in Bonsai, so that's really the only major thing I see.

Input validation is definitely an important consideration. Similar to the above, having the packaged node would make it much easier to upgrade legacy workflows to benefit from improved validation. For example, in the future we could extend this operator to drop or throw if inputs are sent too fast, etc.

Aside from the limited gains from this node, what if we want more control over the Commuator state beyond turning the motor?

This is where having a general CommutatorDevice node would really make this interface shine and again allow us to extend the device or API with extra functionality by simply updating the package.
The easiest way to do this would have been for the commutator to use one of the standard control protocols already integrated into bonsai such as Harp or even ONI itself. This would have allowed us to leverage a bunch of existing infrastructure for configuration, control, logging and synchronization with other devices. In fact, if it was Harp we could even have generated the entire Bonsai interface automatically.
All the questions you asked about how to dynamically parameterize device configuration and having multiple control streams have already been solved for all Harp devices for example. I don't know what microcontroller the commutator uses, but there is now an existing Harp core for the RP2040 (https://github.com/AllenNeuralDynamics/harp.core.rp2040) which would have been perfect for this. A simple version could also be designed on top of other microcontroller architectures, including software forms of clock synchronization which have been implemented for other devices.
Assuming this is not possible for the current hardware / firmware combination:

Make a property in TurnMotor that modifies the string sent to the motor to include the the additional LED state (non-reactive since it changes when the turn command issued)

This is definitely a possibility and I think we could make this pattern work by using a BehaviorSubject in the backend. Whether this is appropriate depends on how big is the full API, and on whether a simple LED toggle is really the only extra functionality. If there are other configuration or control commands which would be useful to expose as streams (now or in the future) this might quickly become too complicated to evolve.

Make a subject in TurnMotor that merges its output sequence with turn commands

I'm not sure I understood this suggestion correctly, but I'm interpreting this to be the same pattern we use for the Harp Device node, which is basically a node which takes a sequence of commands and formats / pipes them to the serial port.
I think this would definitely be flexible enough for all present and future needs. Basically in this pattern we need just two concepts:

A set of commutator nodes (TurnMotor, EnableLed, etc), which format inputs into the corresponding serializable JSON strings (or other protocol) to send to the serial port.
A CommutatorDevice node which establishes a connection to the commutator and receives formatted strings.
(optional) Make the "command" nodes output an abstract base class instead of strings, so that the CommutatorDevice node can declare a "strongly-typed" input. This would immediately disallow accidentally sending random or malformed strings to the device.

I think the last two bullet points would on their own also justify having a CommutatorDevice node.
Even though SerialWriteLine may suffice to send arbitrary strings to the serial port, this operator does not make any assumptions on port configuration properties such as baud rate, etc. Even if the commutator uses the default settings of the bonsai node for now, there is no guarantee this won't change in the future, either on the side of the commutator, or the side of bonsai, so relying on this alignment to be stable in the future is dangerous IMO. Having a common device node would ensure the alignment is enforced and the port configured correctly.
The last point is optional but easy to implement and important for validation to ensure the commutator does not go into an undefined state by accidentally receiving gibberish data from upstream.

We could add a parallel stream in the AutoCommutator workflow that sent {led: false} to a SerialWriteLine with the same port as the TurnMotor. This feels hacky because PortName needs to be defined for both the TurnMotor node and the SerialWriteLine node.

This could actually be done very easily by linking both properties via the same ExternalizedMapping. However, I do agree that it is still hacky because of all the issues discussed above.

These all feel kinda hacky in comparison to defining AutoCommuator as the following:

Seeing the manual control of the motor with keys and LED control functionality added to the AutoCommutator workflow actually makes me feel that what we should really remove is the AutoCommutator node itself.
It feels there are currently two things being conflated in this package:

The commutator device is actually a complex device, so we need all of its functionality to be exposed in a structured way. This is so we can freely compose what we want to do with it in arbitrary ways, e.g. reset commutator on trials, blink LED to signal something, apply a slower drift correction algorithm, untwist commutator with computer vision tracking, etc the list will just keep growing.

There is a need for a "plug-and-play" commutator solution that users can drop into their acquisition workflows to get started quickly doing some recordings.

I feel that 2. could just as easily be provided simply as an example in the commutator docs, with no need for an embedded workflow. This recommended example usage workflow could be updated regularly as we improve the pattern without requiring updates to the commutator package.
That said, I don't disagree we could also make it into an embedded workflow in the package, although in that case I feel it should be fairly minimalistic, e.g. without assuming specific keys or options, since the more we assume the higher is the risk that it will not work for someone's specific workflow.
Originally posted by @glopesdev in https://github.com/open-ephys/bonsai-commutator/issues/2#issuecomment-2282905486

This was at least partially addressed in #11 . The interface is named SerialCommutator since we have tentative plans for a USB/HID version. I don't know if it gets at everything in this proposal and if things are missing feel free to suggest so.

@jonnew I was previously using a vanilla serial operator instead of this custom one. I see you have some nice validation logic in this bespoke operator that I would like to use. However, we were also using few other commands from the provided API (https://open-ephys.github.io/commutator-docs/coax-commutator/user-guide/remote-control.html) and I am not sure how to access those via this operator since the serial object is not exposed.
I can think of a few solutions:

Separate the validation logic from the serial object (not sure if this was something you had in the past and have decided to move away from?)
Expose the serial object to the bonsai context as a resource like any other serial port (Not sure if this is possible due to access)
Adopt something like what Bonsai.Harp does. Have a single operator that receives "CommutatorMessages" (these could potentially have different types that correspond to different API calls) and outputs the async output from the commutator (these could either by just json strings or even the same "CommutatorMessages").

I understand. The operators in here are aimed at ease of use. I guess my suggestion would be just to use QuaternionToTwist in your own workflow with mechanisms for sending the other commands.

authors: bruno-f-cruz glopesdev jonnew

repo: open-ephys/bonsai-commutator


text:
Updated MiniDrugBank molecule sets to fix atom types

This branch was originally to address the parent hierarchy visualization issue #46
So far on that front I've found some nice options using ete2, but I don't think they are going to be super easy to generalize and have them still look good visually. For now, I have not added any of this information.
I did update the molecule files for MiniDrugBank to fix a problem I was having with atomtypes.

This fixes issue #215
The only changes are updating the ipython notebook used to filter molecules, the mol2 files, and the associated README file. @davidlmobley could you merge this?

@davidlmobley I don't want to merge my own pull request could you?

Sorry, I'd missed this request. Thanks, looks good to me.

authors: bannanc davidlmobley

repo: open-forcefield-group/smarty

license: mit


text:
Discuss AWS credits

How credits work and how to save money/use them. Credit expiration.

@alexanderatallah thoughts/help?

repo: open-guides/og-aws


text:
Metadata ingestion for source table RAW datatype vs. OM data type

Context
We currently map source table data types to OpenMetadata types. This is becoming hard to scale, and issues arise when we don't properly map a source type to OM type. These issues arise on the Profiler, where we use the OM DataType to prepare the ORM objects. If the types do not properly match the source types, our queries can be wrong.
Ingestion
We need to validate that our data type can properly cover the raw types of the sources. Right now we add "Varchar" to unknown types, which is not great. At least, use unknown type, but we should improve the coverage here.
Profiler changes
In the profiler ORM converter (link), we can use sqlalchemy dialects to map the RAW types to sqlalchemy types: RAW -> SQLAlchemy instead of RAW -> OM -> SQLAlchemy.
Discussion
Let's discuss possible changes here and their PROs / CONs:

Update table.json#/datatype to string -> This would have many major changes when running the metadata ingestion
Add a new table.json#/rawDataType as string and use that in the ORM converter. We would need to show this one in the UI -> Question, how do we then depracate the dataType change?
Add a new prop in the column systemDataType to store the raw data type

Tasks

[ ] Introduce system data type
[ ] Update profiler ORM converter

For This Issue removing using sqlalchemy dialects to map the RAW types to sqlalchemy types: RAW -> SQLAlchemy instead of RAW -> OM -> SQLAlchemy would not be possible at this point of time because of the following reasons.

The dialect not necessarily support all the data types, for ingestion we had to update this map to add the types which were not supported by dialect
The dialect might not necessarily depend on the map itself to get the sqlalchamy type (for ex. see here  how trino dialect handles some complex types) so to eliminate om type we might have to replicate this logic which could be tedious
OM type also helps to identify types in case of non-sqa sources.

54c5a4916926e0bc1a4f80ba23b89db9459e8f25 commit contains the changes done while exploring these thing which might be useful in case we revisit this issue!

repo: open-metadata/OpenMetadata


text:
Search give 'no results' even with existing data

https://user-images.githubusercontent.com/83201188/149456827-d60b2004-c3ff-42d6-aeef-dac3d0ab0a99.mov

@parthp2107 can you try this with latest master. Please make sure your docker setup is properly installed


text:
Env vars for admin and robot support only 1 admin and 1 robot

Expected behavior
The user would like to provide multiple admins and robot users.
https://github.com/open-metadata/OpenMetadata/blob/d959a49f8d997c8e65c4b10309b720b0060e1271/conf/openmetadata.yaml#L121
https://github.com/open-metadata/OpenMetadata/blob/d959a49f8d997c8e65c4b10309b720b0060e1271/conf/openmetadata.yaml#L123
Propose solution
Use JSON inside the env var.
adminPrincipals: ${AUTHORIZER_ADMIN_PRINCIPALS:-["admin"]}

FYI
@advincze

@advincze Closing for now.
You need only one admin to promote the other users to admin from the UI. So far nobody requested multiple robot users.


text:
UI support for new Service and Ingestion APIs

[x] Schema updation of generated typescripts and integration on UI
[ ] #3924

[x] List APIs

[ ] Get APIs

[ ] Create APIs

[ ] Update APIs

[x] Delete APIs

[ ] #3925
[ ] #3926

link

Ingestion UI.zip

@devyani-kaushik just upload the images directly

Closing for 0.10.0

authors: darth-coder00 devyani-kaushik harshach


text:
UI - unit tests prints too many errors in the console

Affected module
Does it impact the UI, backend or Ingestion Framework?
UI
Describe the bug
A clear and concise description of what the bug is.
Unit tests printing soo many errors
To Reproduce
Screenshots or steps to reproduce

Expected behavior
A clear and concise description of what you expected to happen.
Shouldn't show any errors in console
Version:

OS: [e.g. iOS]
Python version:
OpenMetadata version: [e.g. 0.8]
OpenMetadata Ingestion package version: [e.g. openmetadata-ingestion[docker]==XYZ]

Additional context
Add any other context about the problem here.

Check tests with --detectOpenHandles option


text:
How to obtain inference speed？

How to calculate the inference speed FPs in this paper?
PV-RCNN and so on

Have the same question

We use time.time() with os.environ['CUDA_LAUNCH_BLOCKING'] = '1'

Thank u for your gentle reply! But I'm not familiar enough to your great work. So could u gentlely tell me in detail how to write this code and use it in your OpenPCDet framework? I'll be very appreciated to your instruction.

I Have the same question.I don't know where to put the time module.

Put time.time() here to calculate the forward time:
https://github.com/open-mmlab/OpenPCDet/blob/c233477a4a4bf2861a978794d6b9c047f64641f7/tools/eval_utils/eval_utils.py#L56-L57

Supported in the latest verison with --infer_time keyword

Is there a difference between --infer_time and FPS ?

authors: Jane-QinJ VsionQing ammaryasirnaich jihanyang strugglingguoguo

repo: open-mmlab/OpenPCDet


text:
[Feature] Support resizemix

Motivation
Support resizemix.
paper
Checklist
Before PR:

[ ] Pre-commit or other linting tools are used to fix the potential lint issues.
[ ] Bug fixes are fully covered by unit tests, the case that causes the bug should be added in the unit tests.
[ ] The modification is covered by complete unit tests. If not, please add more unit test to ensure the correctness.
[ ] The documentation has been modified accordingly, like docstring or example tutorials.

After PR:

[ ] If the modification has potential influence on downstream or other related projects, this PR should be tested with those projects, like MMDet or MMSeg.
[ ] CLA has been signed and all committers have signed the CLA in this PR.

Great, I will check it later.

repo: open-mmlab/mmclassification


text:
Searching for help!!!KeyError:'ann_info'

Thanks for your error report and we appreciate it a lot.
Checklist

I have searched related issues but cannot get the expected help.
I have read the FAQ documentation but cannot get the expected help.
The bug has not been fixed in the latest version.

Describe the bug
when i want to train a model, it have run first epoch and begin validation, "KeyError:'ann_info'" arised.
But when i add a parse "--no-validate", it can continue.
Reproduction
CUDA_VISIBLE_DEVICES=1,2,3 bash ./tools/dist_train.sh ./configs/faster_rcnn_r50_fpn_1x_city.py 3 --work-dir ./my_test/

Did you make any modifications on the code or config? Did you understand what you have modified?
What dataset did you use?
Citypersons

Environment

Please run python mmdet/utils/collect_env.py to collect necessary environment information and paste it here.
You may add addition that may be helpful for locating the problem, such as

How you installed PyTorch [e.g., pip, conda, source]
Other environment variables that may be related (such as $PATH, $LD_LIBRARY_PATH, $PYTHONPATH, etc.)

Error traceback
If applicable, paste the error trackback here.
Original Traceback (most recent call last):
  File "/home/oneco/miniconda3/envs/mmdetection/lib/python3.7/site-packages/torch/utils/data/_utils/worker.py", line 198, in _worker_loop
    data = fetcher.fetch(index)
  File "/home/oneco/miniconda3/envs/mmdetection/lib/python3.7/site-packages/torch/utils/data/_utils/fetch.py", line 44, in fetch
    data = [self.dataset[idx] for idx in possibly_batched_index]
  File "/home/oneco/miniconda3/envs/mmdetection/lib/python3.7/site-packages/torch/utils/data/_utils/fetch.py", line 44, in <listcomp>
    data = [self.dataset[idx] for idx in possibly_batched_index]
  File "/home/oneco/mmdetection/mmdet/datasets/custom.py", line 191, in __getitem__
    return self.prepare_test_img(idx)
  File "/home/oneco/mmdetection/mmdet/datasets/custom.py", line 234, in prepare_test_img
    return self.pipeline(results)
  File "/home/oneco/mmdetection/mmdet/datasets/pipelines/compose.py", line 40, in __call__
    data = t(data)
  File "/home/oneco/mmdetection/mmdet/datasets/pipelines/loading.py", line 366, in __call__
    results = self._load_bboxes(results)
  File "/home/oneco/mmdetection/mmdet/datasets/pipelines/loading.py", line 240, in _load_bboxes
    ann_info = results['ann_info']
KeyError: 'ann_info'

Bug fix
If you have already identified the reason, you can provide the information here. If you are willing to create a PR to fix it, please also leave a comment here and that would be much appreciated!

you may check you dataset, ensure annotations is correct

Can you please describe what was the issue? I am facing the same error.

repo: open-mmlab/mmdetection


text:
About MMEditing Inpainting Method DeepFill V2

Thanks for your project, first!
I have tested your Inpainting method DeepFillv2, that got the better results than origin implement. Could you tell me the modifies in your project? And do you modify the network structure?

@nbei OK, I see. Thank you!

repo: open-mmlab/mmediting


text:
我在用mmrazor通过yolov5-x蒸馏yolov5-s时候遇到了问题

Checklist

I have searched related issues but cannot get the expected help.
I have read related documents and don't know what to do.

Describe the question you meet
我使用mmyolo\configs\rtmdet\distillation\kd_s_rtmdet_m_neck_300e_coco.py这个蒸馏的配置文件进行修改提供给yolov5蒸馏使用，但是控制台报错，显示TypeError: optimizer can only optimize Tensors, but one of the params is NoneType
Post related information
这是控制台相关输出
Traceback (most recent call last):
File "D:\python\mmrazor\tools\train.py", line 121, in
main()
File "D:\python\mmrazor\tools\train.py", line 117, in main
runner.train()
File "C:\Users\zhan.conda\envs\mmdetection\lib\site-packages\mmengine\runner\runner.py", line 1734, in train
self.optim_wrapper = self.build_optim_wrapper(self.optim_wrapper)
File "C:\Users\zhan.conda\envs\mmdetection\lib\site-packages\mmengine\runner\runner.py", line 1115, in build_optim_wrapper
return build_optim_wrapper(self.model, optim_wrapper)
File "C:\Users\zhan.conda\envs\mmdetection\lib\site-packages\mmengine\optim\optimizer\builder.py", line 210, in build_optim_wrapper
optim_wrapper = optim_wrapper_constructor(model)
File "d:\python\mmyolo\mmyolo\engine\optimizers\yolov5_optim_constructor.py", line 129, in call
optimizer = OPTIMIZERS.build(optimizer_cfg)
File "C:\Users\zhan.conda\envs\mmdetection\lib\site-packages\mmengine\registry\registry.py", line 570, in build
return self.build_func(cfg, *args, **kwargs, registry=self)
File "C:\Users\zhan.conda\envs\mmdetection\lib\site-packages\mmengine\registry\build_functions.py", line 121, in build_from_cfg
obj = obj_cls(**args)  # type: ignore
File "C:\Users\zhan.conda\envs\mmdetection\lib\site-packages\torch\optim\sgd.py", line 27, in init
super().init(params, defaults)
File "C:\Users\zhan.conda\envs\mmdetection\lib\site-packages\torch\optim\optimizer.py", line 284, in init
self.add_param_group(cast(dict, param_group))
File "C:\Users\zhan.conda\envs\mmdetection\lib\site-packages\torch_compile.py", line 24, in inner
return torch._dynamo.disable(fn, recursive)(*args, **kwargs)
File "C:\Users\zhan.conda\envs\mmdetection\lib\site-packages\torch_dynamo\eval_frame.py", line 451, in _fn
return fn(*args, **kwargs)
File "C:\Users\zhan.conda\envs\mmdetection\lib\site-packages\torch\optim\optimizer.py", line 891, in add_param_group
raise TypeError("optimizer can only optimize Tensors, "
TypeError: optimizer can only optimize Tensors, but one of the params is NoneType
这是我的蒸馏配置文件
base=['yolov5_m-v61_syncbn_fast_8xb16-300e_coco.py']
teacher_ckpt = 'D:\python\mmyolo/models/yolov5_x-v61_syncbn_fast_8xb16-300e_coco_20230305_152943-00776a4b.pth'
norm_cfg = dict(type='BN', affine=False, track_running_stats=False)
#mmyolo::yolov5/yolov5_x-v61_syncbn_fast_8xb16-300e_coco.py
model = dict(
delete=True,
scope='mmrazor',
type='FpnTeacherDistill',
architecture=dict(
cfg_path='mmyolo::yolov5/yolov5_s-v61_syncbn_fast_8xb16-300e_coco.py'),
teacher=dict(
cfg_path='mmyolo::yolov5/yolov5_x-v61_syncbn_fast_8xb16-300e_coco.py'),
teacher_ckpt=teacher_ckpt,
distiller=dict(
type='ConfigurableDistiller',
# recorders are used to record various intermediate results during
# the model forward.
student_recorders=dict(
fpn0=dict(type='ModuleOutputs', source='neck.out_layers.0'),
fpn1=dict(type='ModuleOutputs', source='neck.out_layers.1'),
fpn2=dict(type='ModuleOutputs', source='neck.out_layers.2'),
),
teacher_recorders=dict(
fpn0=dict(type='ModuleOutputs', source='neck.out_layers.0'),
fpn1=dict(type='ModuleOutputs', source='neck.out_layers.1'),
fpn2=dict(type='ModuleOutputs', source='neck.out_layers.2')),
# connectors are adaptive layers which usually map teacher's and
# students features to the same dimension.
connectors=dict(
fpn0_s=dict(
type='ConvModuleConnector',
in_channel=128,
out_channel=320,
bias=False,
norm_cfg=norm_cfg,
act_cfg=None),
fpn0_t=dict(
type='NormConnector', in_channels=320, norm_cfg=norm_cfg),
fpn1_s=dict(
type='ConvModuleConnector',
in_channel=256,
out_channel=640,
bias=False,
norm_cfg=norm_cfg,
act_cfg=None),
fpn1_t=dict(
type='NormConnector', in_channels=640, norm_cfg=norm_cfg),
fpn2_s=dict(
type='ConvModuleConnector',
in_channel=512,
out_channel=1280,
bias=False,
norm_cfg=norm_cfg,
act_cfg=None),
fpn2_t=dict(
type='NormConnector', in_channels=1280, norm_cfg=norm_cfg)),
distill_losses=dict(
loss_fpn0=dict(type='ChannelWiseDivergence', loss_weight=1),
loss_fpn1=dict(type='ChannelWiseDivergence', loss_weight=1),
loss_fpn2=dict(type='ChannelWiseDivergence', loss_weight=1)),
# loss_forward_mappings are mappings between distill loss forward
# arguments and records.
loss_forward_mappings=dict(
loss_fpn0=dict(
preds_S=dict(
from_student=True, recorder='fpn0', connector='fpn0_s'),
preds_T=dict(
from_student=False, recorder='fpn0', connector='fpn0_t')),
loss_fpn1=dict(
preds_S=dict(
from_student=True, recorder='fpn1', connector='fpn1_s'),
preds_T=dict(
from_student=False, recorder='fpn1', connector='fpn1_t')),
loss_fpn2=dict(
preds_S=dict(
from_student=True, recorder='fpn2', connector='fpn2_s'),
preds_T=dict(
from_student=False, recorder='fpn2',
connector='fpn2_t')))))
find_unused_parameters = True
[#](url)
[here]

Your train log file if you meet the problem during training.
[here]
Other code you modified in the mmrazor folder.
[here]

snapshot is good

你好，解决了吗，我也遇到这种问题，卡好几天了

authors: ChinaStark KungFuPandaPro hellowwrod

repo: open-mmlab/mmrazor


text:
Aligning image and text in the same line

Hi, I want to put an image and some text in the same line. For example,
![](data:image/gif;base64,[encoded data, 11300 characters]) Copied

However, no matter I use Message or Markdown component. The text will be pushed to the next line.
If I put the same text in the CommonMark demo site, they will be on the same line.
Is it possible to place them at the same line?

Hi Hans - I'll take a look at this soon and see if I can figure out the root cause of the difference between the CommonMark example and our implementation. Stay tuned!

Hi Hans,
Looking into this, I think I found the problem. In the CommonMark demo site, the CSS display of  tags appears to be display: inline. However, the display property of  tags in Olive Helps is display: block. This would be a change in behavior from what authors currently expect, and I'm not sure if we should take that approach.
What we can do instead is to add an additional configuration property to the Box component, alignItems. Boxes are flexboxes under the hood, and using a combination of justifyContent and alignItems, you can get the alignment you want. We created a ticket HELPS-937 to address this.

This issue has been resolved with the latest LDK release, V3.2.0.

authors: BrettMugglinOlive CandiceCLB epiccoleman hans-hsieh-asus

repo: open-olive/loop-development-kit


text:
feat: add --version to cli

fixes #171

this breaks the build

hmm I guess I am wrong! I seem to recall having already tried this and when published it was broke, but I dont remember now. Lets just roll with it!

Ah right, it works because you are using require ! got it!

@devonwesley when this is done, could you also update the other OpenRPC projects that include CLI to also use this pattern?
in some of them, we still havent converted the cli to TS.

@BelfordZ Yeah, No worries. I'll go through the projects and update them the same way.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

authors: BelfordZ devonwesley

repo: open-rpc/generator-client


text:
Feature: Voting needs context

Type of feature
🍕 Feature
Current behavior
When clicking the button there is no context to what and why this exists. My suggestion is to remove the "voting feature" and instead allow users to add items to an insight page.
https://github.com/open-sauced/ai/assets/5713670/7b048e9b-caef-4e38-badc-5a33992697fc
Suggested solution

Voted repos should have a solid or colored check with a circle
Items not voted should have the circle not colored or filled in.
Check should move to the left.
Add the context of votes from the user to the dropdown.

Additional context
No response
Code of Conduct

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

Contributing Docs

[ ] I agree to follow this project's Contribution Docs

Vote feature also broke alignment on small screens

Closing since we scraped off the Voting feature entirely (for now?).

authors: bdougie diivi

repo: open-sauced/ai


text:
feat: implemented edit list page

Description
Implements the edit list page including an edit list button available on the list's page in the hub.
Note that search currently returns the same list as the page of data currently displayed. I'm creating a PR for the /v1/lists/{id}/contributors endpoint si it's searchable like /v1/lists/contributors via a contributor search term. The rest all works.
https://github.com/open-sauced/app/assets/833231/3069aa70-18d6-4c3d-825f-6434521df26e
What type of PR is this? (check all applicable)

[x] 🍕 Feature
[ ] 🐛 Bug Fix
[ ] 📝 Documentation Update
[ ] 🎨 Style
[ ] 🧑💻 Code Refactor
[ ] 🔥 Performance Improvements
[ ] ✅ Test
[ ] 🤖 Build
[ ] 🔁 CI
[ ] 📦 Chore (Release)
[ ] ⏩ Revert

Related Tickets & Documents

Fixes #1977
Mobile & Desktop Screenshots/Recordings

Added tests?

[ ] 👍 yes
[ ] 🙅 no, because they aren't needed
[ ] 🙋 no, because I need help

Added to documentation?

[ ] 📜 README.md
[ ] 📓 docs.opensauced.pizza
[ ] 🍕 dev.to/opensauced
[ ] 📕 storybook
[ ] 🙅 no documentation needed

[optional] Are there any post-deployment tasks we need to perform?
[optional] What gif best describes this PR or how it makes you feel?

Great stuff, @nickytonline 👏👏.
Some observations with the pagination... if i next the page using the arrow icon, it doesn’t reflect on the page number.
https://github.com/open-sauced/app/assets/62995161/6e4240b6-cf25-46fa-a334-2124ef5f7082
And secondly, if we have up to 100 pages, will this truncate after XYZ length?

Great stuff, @nickytonline 👏👏.
Some observations with the pagination... if i next the page using the arrow icon, it doesn’t reflect on the page number. open-sauced/app/assets/62995161/6e4240b6-cf25-46fa-a334-2124ef5f7082
And secondly, if we have up to 100 pages, will this truncate after XYZ length?

Thanks for reviewing @OgDev-01! I hadn't thought of that as I had assumed the paging component managed all this internally, but I hadn't checked.
I might just go to our default paging component for now since a lot of that is baked in.

The API has been updated, so you can now filter on user list contributors.
Just sorting out the styling of the paging @OgDev-01.

The copy in this poppup looks to not be centered - not sure where else this gets used, not seeing it else where in the app

The user experience of selecting "edit list" -> "Add new contributors" -> adding contirbutors in the list -> the above popup -> selecting "Done" -> being back to the list overview page is abit confusing.
My expectation would be that after selecting "Done" I'd be taken back to the list edit page with those new contributors populated. If you think of it like a stack, popping off the stack all the way out to the list overview page feels like one too many.
Looks like this list page needs some styling? Note the off white background:

This is overall looking amazing!!! Nice work Nick!

I think the centering issue is just on Firefox as it's fine in Chromium based browsers. Gonna check in Safari as well.
I believe the original designs had you going back to the list overview, but I agree going back to the edit page makes more sense.

The copy in this poppup looks to not be centered - not sure where else this gets used, not seeing it else where in the app

The user experience of selecting "edit list" -> "Add new contributors" -> adding contirbutors in the list -> the above popup -> selecting "Done" -> being back to the list overview page is abit confusing.
My expectation would be that after selecting "Done" I'd be taken back to the list edit page with those new contributors populated. If you think of it like a stack, popping off the stack all the way out to the list overview page feels like one too many.
Looks like this list page needs some styling? Note the off white background:

This is overall looking amazing!!! Nice work Nick!

I think the centering issue is just on Firefox as it's fine in Chromium based browsers. Gonna check in Safari as well.
I believe the original designs had you going back to the list overview, but I agree going back to the edit page makes more sense.

All fixed @jpmcb

Still sorting out the paging component since it's never been used with the pages prop aside from an empty array.
If you could take the rest for a spin again when you have a sec @OgDev-01, 🙏

@OgDev-01, I've fixed the paging logic so this is good to go whenever you have time for more feedback.
https://github.com/open-sauced/app/assets/833231/c356b507-3dee-4a2b-9c81-4e96e26c1b5c

I chatted with @isabensusan and she made a couple style changes. I'm going to go ahead and merge this now that it's got her seal of approval. ✅

repo: open-sauced/app


text:
fix: Rename "Technical Guide" category to "app.opensauced.pizza"

What type of PR is this? (check all applicable)

[ ] 🍕 Feature
[ ] 🐛 Bug Fix
[x] 📝 Documentation Update
[ ] 🎨 Style
[ ] 🧑💻 Code Refactor
[ ] 🔥 Performance Improvements
[ ] ✅ Test
[ ] 🤖 Build
[ ] 🔁 CI
[ ] 📦 Chore (Release)
[ ] ⏩ Revert

Description

Renamed “Technical Guide” category to "app.opensauced.pizza"
Related Tickets & Documents

fix #50
Mobile & Desktop Screenshots/Recordings

Added tests?

[ ] 👍 yes
[x] 🙅 no, because they aren't needed
[ ] 🙋 no, because I need help

Added to documentation?

[ ] 📜 README.md
[ ] 📓 docs.opensauced.pizza
[ ] 🍕 dev.to/opensauced
[ ] 📕 storybook
[x] 🙅 no documentation needed

[optional] Are there any post-deployment tasks we need to perform?
[optional] What gif best describes this PR or how it makes you feel?

Hello @Vinitvh
Please rename the folder ./docs/technical/ to ./docs/AppOpensauce as well

With this change, I would recommend resolve-merge-conflicts be moved to the Contributing guide section, since it is not app.opensauced.pizza specific.

moving in a different direction for the docs.

authors: Deadreyo Vinitvh bdougie


text:
wip: feat: Change AICOE-CI from Docker strategy to source

Still work in progress, working on addressing - build image using s2i in documentation.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign tumido after the PR has been reviewed.
You can assign the PR to them by writing /assign @tumido in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/deploy

i understand this is still WIP.
just one comment:
registry.redhat.io/ubi8/nodejs-16:latest would require redhat subscribed creds to build.
can we change it with registry.access.redhat.com/ubi8/nodejs-16:latest, it is available.

i understand this is still WIP. just one comment: registry.redhat.io/ubi8/nodejs-16:latest would require redhat subscribed creds to build. can we change it with registry.access.redhat.com/ubi8/nodejs-16:latest, it is available.

@harshad16 good point thanks :+1: .

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: tumido
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [tumido]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

I think I m late to the party, just one question for my self-knowledge,
why do we have a separate script, the description of using the s2i build command would have done the trick, right?
PS: no changes needed, just asking for knowledge

authors: harshad16 mimotej sesheta


text:
[FEAT]完形填空支持多个空白

大佬，是否可以解决完形填空只能显示一个空的问题？

Sir, I found someone else had soved this problem, aosr, this plugin based on obsidian-spaced-repetition can recognize tag "#multicloze" to display multicloze, but other functions in that plugin changed a lot, I didn't like it, I really beg you to incorporate "#multicloze" function from aosr, thanks a lot.

这个以后有空再吧，最近时间有限。
或者你fork改下。

我没意见，我只管算法相关的。

主分支有人提，但效果不好，就没有合并过来。
如果只是想点哪显示哪，ob中文论坛 有人通过css 方式实现了
---原始邮件---
发件人: @.>
发送时间: 2024年1月18日(周四) 下午3:02
收件人: @.>;
抄送: @.@.>;
主题: Re: [open-spaced-repetition/obsidian-spaced-repetition-recall] [FEAT]完形填空支持多个空白 (Issue #4)
想要multicloze的功能, 然后可以自由猜, 点哪个空翻转哪个空, 效率高些. 在obsidian中用srs一般是围绕笔记开展的, 没有专门弄成问答等形式, 直接全篇内容重点加粗, 然后自由猜, 强化对笔记的记忆, 也减小了记笔记时的摩擦力
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>

目前最新版已经支持了 https://github.com/open-spaced-repetition/obsidian-spaced-repetition-recall/releases/latest

authors: L-M-Sherlock Newdea xh542428798


text:
Update contributing guidelines

Make clear that we will no longer accept PR's from protected forks.

fucking markdownlint

repo: open-telemetry/opentelemetry-demo


text:
Improve test matrix and add support for Elixir 1.15 and OTP 26

I wanted to prove one of the libraries worked on OTP 26 and Elixir 1.15, but hit a wall of errors. I had a go at fixing most of them.

Implemented the matrix being read from the files, as was originally intended (from what I can tell)
Added support for building on OTP 26 and Elixir 1.15, including upgrading the dependencies on projects which require ssl_verify_fun as only >= 1.1.7 builds on Elixir 1.15
I added support for only running mix format --check-formatted on a specific version of Elixir - the formatter implementation changed subtly between 1.14 and 1.15, so tests will fail

Outstanding issues:

Some libraries require 1.12 or 1.14 minimum, but we still attempt to run the entire matrix on them. We should conditionally check whether the environment is new enough to support the project before running the workflow.

Hm, wonder if there is a way to make this actually run the tests on all these that it effects. @bryannaegele any idea?

Hm, wonder if there is a way to make this actually run the tests on all these that it effects. @bryannaegele any idea?

You or I have to trigger the build because they aren't an org member. You can just remove/add scope-ci to kick it.

Ah cool, thanks.
So yea, some of these fail, haven't looked at why yet.

There’s a range of reasons why the remaining stuff fails, but from what I can see there’s two groups:

Libraries which set minimum Elixir version requirements but are being run with a test matrix of lower version requirements and immediately bailing out
Libraries which have actually failing tests or compilation warnings which should be addressed in the library code

For the first group, we could read the minimum version from mix.exs and check whether it meets the running version and bail out early if not.

We should have a minimum version of elixir for all libraries. I think we were planning on the last 2 major releases, so 1.15 and 1.14?
If the test matrix was just 1.15 and 1.14 would that work then? (Aside from the library issues we need to resolve separately)

I think we were trying to match the support levels we have in beam-telemetry. Whatever the "official" levels are for Elixir. I think it's in the Elixir docs.

@tsloughter I don't think any libraries require > 1.14, so setting the matrix to 1.14 + 1.15 would work for this class of failing test.

OK, I think that's everything passing now. I've fixed a bunch of minor issues in libraries, and aligned all the formatting with 1.15. We now only test on 1.14 and 1.15 and a matrix of recent OTP versions.

@tsloughter I asked Jóse what he thought since I think we want to try to keep support as close to our beam-telemetry support which is currently 5 Elixir versions which means covering OTP 21 which is still the problematic one. Do we want to adopt a formal policy on last 3 OTP versions? That would take us to OTP 23+ and a min Elixir support of 1.11.4. He seemed good with that.
I just want to align this repo as much as possible to what we want to formally support in otel/otel api.
https://hexdocs.pm/elixir/compatibility-and-deprecations.html

@bryannaegele yea, 3 is good, that is what we do for rebar3 as well.

Ok. Let's actually do 4 and match what we support in otel/otel api. I'd like anything in contrib to be usable with the main libraries.
@tomtaylor we will want to update the matrix then to have Elixir versions down to 1.11.4 and OTP 23 and correct anything from there.

I've pinned Elixir + OTP to specific versions and included the versions discussed, and I suspect there are still some failing libraries, but I don't have permissions add/remove labels to fix Github Actions to run them. Could someone take a look?

argh, some setup-beam error as usual :) https://github.com/open-telemetry/opentelemetry-erlang-contrib/actions/runs/5974597901/job/16209053026?pr=188

argh, some setup-beam error as usual :) https://github.com/open-telemetry/opentelemetry-erlang-contrib/actions/runs/5974597901/job/16209053026?pr=188

That looks to me like the server returned an error looking up that version. Every job in the workflow requests rebar 3.20 and installed it correctly, bar that one. I suspect it'd work on a retry.

Formatting issue https://github.com/open-telemetry/opentelemetry-erlang-contrib/actions/runs/5974597901/job/16210352781?pr=188

I think that landed with https://github.com/open-telemetry/opentelemetry-erlang-contrib/pull/198/commits/6e40de665a8ef39626533ceb74e93db0792dde07

Ah, must have been added when I ran the update on this PR.
Can you run the formatter again and update this PR?

Done and all passing - quick, merge it in before something else lands!

authors: bryannaegele tomtaylor tsloughter


text:
fix: allow hapi plugin from array to be registered as argument

Which problem is this PR solving?
I missed this in #1046.
HAPI plugins can be registered directly as objects, with server.register(plugin). But they can also be registered as an array, with server.register([plugin]).
Right now, we only accept server.register([{plugin: plugin}]);, which doesn't match the hapi documentation.
See https://hapi.dev/tutorials/plugins/?lang=en_US#loading
Short description of the changes
Allow registering hapi plugins from an array when the object is passed directly, and they are not nested within a deeper object.

Failing browser test seems unrelated to the changes in this PR.

repo: open-telemetry/opentelemetry-js-contrib


text:
feat: add semconv generator for semantic-conventions-package

Which problem is this PR solving?
Adds a build script which generate the files for the semantic-conventions-package
so it always in sync with the definitions in the specifications-repo
A few unspecified attributes are added manually to the semconv template to
allow existing code to pass, these are:
  // HTTP
  HTTP_ERROR_NAME: 'http.error_name',
  HTTP_ERROR_MESSAGE: 'http.error_message',
  HTTP_STATUS_TEXT: 'http.status_text',

  // GRPC
  GRPC_KIND: 'grpc.kind', // SERVER or CLIENT
  GRPC_METHOD: 'grpc.method',
  GRPC_STATUS_CODE: 'grpc.status_code',
  GRPC_ERROR_NAME: 'grpc.error_name',
  GRPC_ERROR_MESSAGE: 'grpc.error_message',

Fixes #2064
Short description of the changes
This change introduces a script generate.sh in the directory scripts/semconv which allows you to generate the constants which are defined in the semantic conventions section of the Opentelemetry specification.
The following to files are generated:

SemanticAttribute
ResourceAttribute

All the packages that depend on the @opentelemetry/semantic-conventions-package has been updated to accommodate this change.
To allow this version of the spec files to work with the semconv the
version of this tool had to be lowered to 0.2.1 as there is a breaking
change in 0.3.0 which removes support for the number-type and
because the latest published version of the otel spec is v1.1.0 which
still uses this number-type.

I have to make some more changes related to this ticket: https://github.com/open-telemetry/build-tools/issues/41
But  looking forward hearing if this approach is fine. Having a second look I am not sure if we want to name it ResourceAttributes and SemanticAttributes (plural)

I have to make some more changes related to this ticket: open-telemetry/build-tools#41
But looking forward hearing if this approach is fine. Having a second look I am not sure if we want to name it ResourceAttributes and SemanticAttributes (plural)

I would for sure prefer ResourceAttributes and SpanAttributes. Technically they are all semantic attributes so that name doesn't really add much.

I have to make some more changes related to this ticket: open-telemetry/build-tools#41
But looking forward hearing if this approach is fine. Having a second look I am not sure if we want to name it ResourceAttributes and SemanticAttributes (plural)

I would for sure prefer ResourceAttributes and SpanAttributes. Technically they are all semantic attributes so that name doesn't really add much.

I have renamed ResourceAttributes but for now using SemanticAttributes mainly because we already have SpanAttributes in the api-package which I think could cause confusion. But I am happy make the name change to SpanAttributes if the potential conflict/confusion is of no concern.

Something is wrong during merging with main branch you have restored all the removed plugins

Yes, sorry about that, I noticed that too. Think it's resolved now. Sourcetree is confusing with displaying deleted files when you have changes to the same files

Thank you for approving :D

authors: dyladan weyert

repo: open-telemetry/opentelemetry-js


text:
fix: use interface instead of class in SpanProcessor#onStart

Which problem is this PR solving?
Fixes: https://github.com/open-telemetry/opentelemetry-js/issues/2845
Short description of the changes
Using the span class doesn't hide the private properties. This results in typescript complains if the Span class is visible in two .d.ts files (e.g. two versions of the same package installed).
This is avoided by using a type reflecting only the public interface of the class.
Type of change

[x] Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?
Checklist:

[x] Followed the style guidelines of this project
[ ] Unit tests have been added
[ ] Documentation has been updated

moved it to draft as I think there is more needed to solve the linked issue.

Resource is also a class
this is returned which seems to be still have the class type after Pick<Span, keyof Span>

Closing as this would require a more generic aproach not limited to span class only. Instead classes should be avoided at all in public APIs. see https://github.com/open-telemetry/opentelemetry-js/pull/2863#issuecomment-1085588987


text:
refactor(exporters): introduce packages for shared exporter classes

Which problem is this PR solving?
Currently the metrics exporters depend on the trace exporters, which causes unwanted dependencies to Trace packages via the Metrics exporters. This PR is part of the work to get rid of these dependencies by introducing new packages for Trace-independent export code that was previously exported from the exporter-trace-otlp-grpc, exporter-trace-otlp-http and exporter-trace-otlp-proto packages.
These shared classes have been moved to otlp-exporter-base, otlp-grpc-exporter-base and otlp-proto-exporter-base. Therefore,

opentelemetry-exporter-metrics-otlp-http
opentelemetry-exporter-metrics-otlp-proto
opentelemetry-exporter-metrics-otlp-grpc
exporter-trace-otlp-grpc
exporter-trace-otlp-http
exporter-trace-otlp-proto

have been updated to make use of these new packages instead.
While the exporters still depend on exporter-trace-otlp-http for transformation of the internal types to the proto-representation, this can be handled in a follow-up PR.
Related Issue: #2886
Short description of the changes
Type of change
Please delete options that are not relevant.

[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)

since previously exported classes have been moved to other packages. Other than that, this is a pure refactor.

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[x] Unit tests moved over from the original packages.

Checklist:

[x] Followed the style guidelines of this project
[ ] Unit tests have been added
[ ] Documentation has been updated

@pichlermarc hi, could you please provide an update on this? I wonder what's the ETA. Thx

@pichlermarc hi, could you please provide an update on this? I wonder what's the ETA. Thx

I'm not in the office this week, so I handed this PR over to @dyladan while I'm away. It is pretty much done though, but when I left some checks were failing.

There is still some minor cleanup but i'll mark it as ready for review so we can get some 👀 on it

Hi team,
Are we good here to move forward?

Currently the metrics exporters depend on the trace exporters, which causes unwanted dependencies to Trace packages via the Metrics exporters

What is the plan for the future for these exporters? do we plan to keep them separated or merge them into a single exporter per-protocol that can export all stable signals (trace, metrics, and logs in the future)?
I don't see any good reason to separate them once metrics is stable, in which case we will probably need to merge these new packages back soon, right?
If we do want them separated in the future as well, should we also split the otlp-transformer package into per-signal packages?

As far as I know the exporters were split by signal in order to keep bundle size down. This was originally done by @obecny. Personally I think the developer experience is better to have a single exporter for all signals, but I'm not sure how much this affects the bundle size. Maybe @MSNev has some idea?

When it was used in for example aws lambda (if I remember correctly) you don't want to have many MB as there is already a limit for your function. The same applies for browser you don't want to load many unneeded MB or kB of code. So hence the decision to split them so the user can include only what is necessary

Even if we merged trace/metrics OTLP exporters into one stable package, I think in the case of reducing bundle size in certain environments, people could still use tools to tree-shaking unused code components.

authors: blumamir dyladan kumarrishav legendecas morigs obecny pichlermarc


text:
Release v1.3.1

Supersedes https://github.com/open-telemetry/opentelemetry-proto-go/pull/166.
Release of the v1.3.1 version of the OTLP including the new Profiles signal.

To help reviewing this PR:
Only changes in Makefile and versions.yaml are hand made. All other code changes are auto generated by make sync.

Ideally, we merge https://github.com/open-telemetry/opentelemetry-proto-go/pull/177, or something equivalent, before this is released.

authors: MrAlias florianl

repo: open-telemetry/opentelemetry-proto-go


text:
PG Patch Segmentation Fault

We randomly see segmentation faults within opentelemetry-instrumentation-pg (0.24).
This does not seem to affect our application though I did not see a report of it either.

Share details about your runtime
Operating system details: Linux, Ubuntu 20.04.6 LTS (Heroku)
RUBY_ENGINE: "ruby"
RUBY_VERSION: "3.1.4"
RUBY_DESCRIPTION: "ruby 3.1.4p223 (2023-03-30 revision 957bb7cb81) [x86_64-linux]"
opentelemetry-api: 1.1.0
opentelemetry-common: 0.19.6
opentelemetry-sdk: 1.2.0
Backtrace
/app/vendor/bundle/ruby/3.1.0/gems/opentelemetry-instrumentation-pg-0.24.0/lib/opentelemetry/instrumentation/pg/patches/connection.rb:20: [BUG] Segmentation fault at 0x000000000000009e
ruby 3.1.4p223 (2023-03-30 revision 957bb7cb81) [x86_64-linux]
-- Control frame information -----------------------------------------------
c:0199 p:---- s:1279 e:001278 CFUNC  :exec_params
c:0198 p:0008 s:1273 e:001272 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/opentelemetry-instrumentation-pg-0.24.0/lib/opentelemetry/instrumentation/pg/patches/connect
c:0197 p:0006 s:1270 e:001269 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/opentelemetry-api-1.1.0/lib/opentelemetry/trace.rb:72
c:0196 p:0024 s:1265 e:001264 METHOD /app/vendor/bundle/ruby/3.1.0/gems/opentelemetry-api-1.1.0/lib/opentelemetry/context.rb:87
c:0195 p:0023 s:1257 e:001256 METHOD /app/vendor/bundle/ruby/3.1.0/gems/opentelemetry-api-1.1.0/lib/opentelemetry/trace.rb:72
c:0194 p:0035 s:1252 e:001251 METHOD /app/vendor/bundle/ruby/3.1.0/gems/opentelemetry-api-1.1.0/lib/opentelemetry/trace/tracer.rb:29
c:0193 p:0028 s:1239 e:001238 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/opentelemetry-instrumentation-pg-0.24.0/lib/opentelemetry/instrumentation/pg/patches/connect [FINISH]
c:0192 p:0011 s:1233 e:001232 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/activerecord-6.1.7.3/lib/active_record/connection_adapters/postgresql_adapter.rb:672
c:0191 p:0002 s:1230 e:001229 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/activesupport-6.1.7.3/lib/active_support/dependencies/interlock.rb:48
c:0190 p:0022 s:1227 e:001226 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activesupport-6.1.7.3/lib/active_support/concurrency/share_lock.rb:187
c:0189 p:0008 s:1217 e:001216 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activesupport-6.1.7.3/lib/active_support/dependencies/interlock.rb:47
c:0188 p:0018 s:1213 e:001212 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/activerecord-6.1.7.3/lib/active_record/connection_adapters/postgresql_adapter.rb:671
c:0187 p:0002 s:1210 e:001209 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/activerecord-6.1.7.3/lib/active_record/connection_adapters/abstract_adapter.rb:696
c:0186 p:0002 s:1207 e:001206 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/activesupport-6.1.7.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:26 [FINISH]
c:0185 p:---- s:1204 e:001203 CFUNC  :handle_interrupt
c:0184 p:0026 s:1199 e:001198 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/activesupport-6.1.7.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25 [FINISH]
c:0183 p:---- s:1196 e:001195 CFUNC  :handle_interrupt
c:0182 p:0021 s:1191 e:001190 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activesupport-6.1.7.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21
c:0181 p:0007 s:1187 e:001186 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/activerecord-6.1.7.3/lib/active_record/connection_adapters/abstract_adapter.rb:695
c:0180 p:0022 s:1183 e:001182 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activesupport-6.1.7.3/lib/active_support/notifications/instrumenter.rb:24
c:0179 p:0034 s:1175 e:001174 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activerecord-6.1.7.3/lib/active_record/connection_adapters/abstract_adapter.rb:687
c:0178 p:0033 s:1166 e:001165 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activerecord-6.1.7.3/lib/active_record/connection_adapters/postgresql_adapter.rb:670
c:0177 p:0061 s:1158 e:001157 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activerecord-6.1.7.3/lib/active_record/connection_adapters/postgresql_adapter.rb:649
c:0176 p:0020 s:1147 e:001146 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activerecord-6.1.7.3/lib/active_record/connection_adapters/postgresql/database_statements.rb
c:0175 p:0018 s:1138 e:001137 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activerecord-6.1.7.3/lib/active_record/connection_adapters/abstract/database_statements.rb:5
c:0174 p:0061 s:1131 e:001130 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activerecord-6.1.7.3/lib/active_record/connection_adapters/abstract/database_statements.rb:6
c:0173 p:0012 s:1121 e:001120 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/activerecord-6.1.7.3/lib/active_record/connection_adapters/abstract/query_cache.rb:101
c:0172 p:0066 s:1118 e:001114 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/activerecord-6.1.7.3/lib/active_record/connection_adapters/abstract/query_cache.rb:118
c:0171 p:0002 s:1111 e:001110 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/activesupport-6.1.7.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:26 [FINISH]
c:0170 p:---- s:1108 e:001107 CFUNC  :handle_interrupt
c:0169 p:0026 2023-05-01T16:13:57.190173 : [c7a7f134-1038-4708-a74b-5642536cac26] Processing by REDACTED#REDACTED as V3
s:1103 e:001102 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/activesupport-6.1.7.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25 [FINISH]
c:0168 p:---- s:1100 e:001099 CFUNC  :handle_interrupt
c:0167 p:0021 s:1095 e:001094 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activesupport-6.1.7.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21
c:0166 p:0006 s:1091 e:001090 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activerecord-6.1.7.3/lib/active_record/connection_adapters/abstract/query_cache.rb:109
c:0165 p:0056 s:1084 e:001083 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activerecord-6.1.7.3/lib/active_record/connection_adapters/abstract/query_cache.rb:101
c:0164 p:0024 s:1074 e:001073 BLOCK  /app/lib/freedom_patches/activerecord_calculation_logging.rb:20
c:0163 p:0012 s:1071 e:001070 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activerecord-6.1.7.3/lib/active_record/relation.rb:861
c:0162 p:0089 s:1067 e:001066 METHOD /app/lib/freedom_patches/activerecord_calculation_logging.rb:20
c:0161 p:0051 s:1060 e:001058 METHOD /app/app/components/conversations/collection_members_query.rb:195
c:0160 p:0003 s:1055 e:001054 METHOD /app/app/components/conversations/collection_members_query.rb:200
2023-05-01T16:13:57.190334 : [c7a7f134-1038-4708-a74b-5642536cac26] Parameters: {REDACTED}
c:0159 p:0051 s:1050 e:001040 BLOCK  /app/app/components/conversations/collection_members_query.rb:28 [FINISH]
c:0158 p:---- s:1037 e:001036 IFUNC
c:0157 p:---- s:1034 e:001033 CFUNC  :each
c:0156 p:0017 s:1030 e:001029 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activerecord-6.1.7.3/lib/active_record/relation/delegation.rb:88 [FINISH]
c:0155 p:---- s:1022 e:001021 CFUNC  :map
c:0154 p:0013 s:1018 e:001017 METHOD /app/app/components/conversations/collection_members_query.rb:18
c:0153 p:0003 s:1014 e:001013 METHOD /app/vendor/ruby-3.1.4/lib/ruby/3.1.0/forwardable.rb:232 [FINISH]
c:0152 p:---- s:1007 e:001006 CFUNC  :to_a
c:0151 p:---- s:1004 e:001003 CFUNC  :Array
c:0150 p:0007 s:0999 e:000998 METHOD /app/vendor/bundle/ruby/3.1.0/gems/dry-types-1.5.1/lib/dry/types/constructor/function.rb:72
c:0149 p:0010 s:0992 e:000990 METHOD /app/vendor/bundle/ruby/3.1.0/gems/dry-types-1.5.1/lib/dry/types/constructor.rb:87
c:0148 p:0031 s:0986 e:000985 METHOD /app/vendor/bundle/ruby/3.1.0/gems/dry-types-1.5.1/lib/dry/types/type.rb:49
c:0147 p:0045 s:0980 e:000979 METHOD /app/lib/heracles/property.rb:36
c:0146 p:0006 s:0972 e:000971 METHOD /app/lib/heracles/serializers/hydra.rb:25
c:0145 p:0014 s:0965 e:000961 BLOCK  /app/lib/heracles/serializers/hydra.rb:18 [FINISH]
c:0144 p:---- s:0957 e:000956 IFUNC
c:0143 p:---- s:0954 e:000953 CFUNC  :each
c:0142 p:---- s:0951 e:000950 CFUNC  :with_object
c:0141 p:0044 s:0946 e:000945 METHOD /app/lib/heracles/serializers/hydra.rb:17
c:0140 p:0027 s:0940 e:000939 METHOD /app/lib/heracles/resource.rb:74
c:0139 p:0027 s:0934 e:000933 METHOD /app/app/shields/application_shield.rb:30
c:0138 p:0015 s:0928 e:000926 BLOCK  /app/lib/heracles/railtie.rb:23
c:0137 p:0033 s:0924 e:000923 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activesupport-6.1.7.3/lib/active_support/notifications.rb:205
c:0136 p:0123 s:0918 e:000917 BLOCK  /app/lib/heracles/railtie.rb:22 [FINISH]
c:0135 p:0043 s:0909 e:000908 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_controller/metal/renderers.rb:150 [FINISH]
c:0134 p:---- s:0904 e:000903 CFUNC  :each_key
c:0133 p:0022 s:0900 e:000899 METHOD /app/vendor/ruby-3.1.4/lib/ruby/3.1.0/set.rb:511
c:0132 p:0006 s:0895 E:001e28 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_controller/metal/renderers.rb:146
c:0131 p:0005 s:0890 e:000889 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_controller/metal/renderers.rb:142
c:0130 p:0018 s:0885 e:000884 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/abstract_controller/rendering.rb:25
c:0129 p:0033 s:0877 e:000876 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_controller/metal/rendering.rb:36
c:0128 p:0009 s:0872 e:000871 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_controller/metal/instrumentation.rb:46
c:0127 p:0028 s:0869 e:000868 METHOD /app/vendor/ruby-3.1.4/lib/ruby/3.1.0/benchmark.rb:311
c:0126 p:0009 s:0864 e:000862 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activesupport-6.1.7.3/lib/active_support/core_ext/benchmark.rb:14
c:0125 p:0012 s:0858 e:000857 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_controller/metal/instrumentation.rb:46
c:0124 p:0002 s:0855 e:000854 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_controller/metal/instrumentation.rb:86
c:0123 p:0066 s:0851 e:000850 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activerecord-6.1.7.3/lib/active_record/railties/controller_runtime.rb:34
c:0122 p:0008 s:0844 e:000842 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_controller/metal/instrumentation.rb:45
c:0121 p:0066 s:0837 e:000836 METHOD /app/app/controllers/conversation_filters_controller.rb:32
c:0120 p:0010 s:0832 e:000831 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_controller/metal/basic_implicit_render.rb:6
c:0119 p:0009 s:0826 e:000825 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/abstract_controller/base.rb:228
c:0118 p:0024 s:0820 e:000819 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_controller/metal/rendering.rb:30
c:0117 p:0008 s:0815 e:000814 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/abstract_controller/callbacks.rb:42
c:0116 p:0048 s:0812 e:000810 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/activesupport-6.1.7.3/lib/active_support/callbacks.rb:117
c:0115 p:0037 s:0802 e:000801 METHOD /app/app/controllers/api_controller.rb:91
c:0114 p:0127 s:0797 e:000796 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/activesupport-6.1.7.3/lib/active_support/callbacks.rb:126
c:0113 p:0123 s:0788 E:002088 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activesupport-6.1.7.3/lib/active_support/callbacks.rb:137
c:0112 p:0006 s:0779 E:001388 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/abstract_controller/callbacks.rb:41
c:0111 p:0008 s:0774 e:000773 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_controller/metal/rescue.rb:22
c:0110 p:0009 s:0768 e:000767 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_controller/metal/instrumentation.rb:34
c:0109 p:0010 s:0763 e:000762 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/activesupport-6.1.7.3/lib/active_support/notifications.rb:203
c:0108 p:0022 s:0760 e:000759 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activesupport-6.1.7.3/lib/active_support/notifications/instrumenter.rb:24
c:0107 p:0023 s:0752 e:000751 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activesupport-6.1.7.3/lib/active_support/notifications.rb:203
c:0106 p:0098 s:0746 e:000745 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_controller/metal/instrumentation.rb:33
c:0105 p:0017 s:0740 e:000739 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_controller/metal/params_wrapper.rb:249
c:0104 p:0026 s:0735 e:000734 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activerecord-6.1.7.3/lib/active_record/railties/controller_runtime.rb:27
c:0103 p:0070 s:0729 e:000728 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/abstract_controller/base.rb:165
c:0102 p:0067 s:0722 e:000721 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionview-6.1.7.3/lib/action_view/rendering.rb:39
c:0101 p:0017 s:0716 e:000715 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_controller/metal.rb:190
c:0100 p:0177 s:0709 e:000708 METHOD /app/vendor/bundle/ruby/3.1.0/gems/opentelemetry-instrumentation-action_pack-0.6.0/lib/opentelemetry/instrumentation/action_pac
c:0099 p:0033 s:0700 e:000699 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_controller/metal.rb:254
c:0098 p:0010 s:0693 e:000692 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_dispatch/routing/route_set.rb:50
c:0097 p:0036 s:0685 e:000684 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_dispatch/routing/route_set.rb:33
c:0096 p:0006 s:0677 e:000676 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_dispatch/routing/mapper.rb:19
c:0095 p:0026 s:0672 e:000671 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_dispatch/routing/mapper.rb:49
c:0094 p:0109 s:0667 e:000666 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_dispatch/journey/router.rb:50 [FINISH]
c:0093 p:---- s:0654 e:000653 CFUNC  :each
c:0092 p:0008 s:0650 e:000649 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_dispatch/journey/router.rb:32
c:0091 p:0042 s:0645 e:000644 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_dispatch/routing/route_set.rb:842
c:0090 p:0185 s:0639 e:000638 METHOD /app/vendor/bundle/ruby/3.1.0/gems/rack-attack-6.6.1/lib/rack/attack.rb:127
c:0089 p:0113 s:0633 e:000632 METHOD /app/vendor/bundle/ruby/3.1.0/gems/flipper-0.28.0/lib/flipper/middleware/memoizer.rb:72
c:0088 p:0031 s:0626 e:000625 METHOD /app/vendor/bundle/ruby/3.1.0/gems/flipper-0.28.0/lib/flipper/middleware/memoizer.rb:37
c:0087 p:0020 s:0620 e:000619 METHOD /app/vendor/bundle/ruby/3.1.0/gems/sidekiq-pro-4.0.5/lib/sidekiq/rack/batch_status.rb:34
c:0086 p:0157 s:0613 e:000612 METHOD /app/vendor/bundle/ruby/3.1.0/gems/omniauth-2.0.4/lib/omniauth/strategy.rb:202
c:0085 p:0007 s:0606 e:000605 METHOD /app/vendor/bundle/ruby/3.1.0/gems/omniauth-2.0.4/lib/omniauth/strategy.rb:169
c:0084 p:0157 s:0601 e:000600 METHOD /app/vendor/bundle/ruby/3.1.0/gems/omniauth-2.0.4/lib/omniauth/strategy.rb:202
c:0083 p:0007 s:0594 e:000593 METHOD /app/vendor/bundle/ruby/3.1.0/gems/omniauth-2.0.4/lib/omniauth/strategy.rb:169
c:0082 p:0157 s:0589 e:000588 METHOD /app/vendor/bundle/ruby/3.1.0/gems/omniauth-2.0.4/lib/omniauth/strategy.rb:202
c:0081 p:0007 s:0582 e:000581 METHOD /app/vendor/bundle/ruby/3.1.0/gems/omniauth-2.0.4/lib/omniauth/strategy.rb:169
c:0080 p:0157 s:0577 e:000576 METHOD /app/vendor/bundle/ruby/3.1.0/gems/omniauth-2.0.4/lib/omniauth/strategy.rb:202
c:0079 p:0007 s:0570 e:000569 METHOD /app/vendor/bundle/ruby/3.1.0/gems/omniauth-2.0.4/lib/omniauth/strategy.rb:169
c:0078 p:0007 s:0565 e:000564 METHOD /app/vendor/bundle/ruby/3.1.0/gems/omniauth-2.0.4/lib/omniauth/builder.rb:45
c:0077 p:0026 s:0560 e:000559 METHOD /app/vendor/bundle/ruby/3.1.0/gems/rack-2.2.7/lib/rack/session/abstract/id.rb:266
c:0076 p:0005 s:0549 e:000548 METHOD /app/vendor/bundle/ruby/3.1.0/gems/rack-2.2.7/lib/rack/session/abstract/id.rb:260
c:0075 p:0026 s:0544 e:000543 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_dispatch/middleware/cookies.rb:697
c:0074 p:0092 s:0534 e:000533 METHOD /app/vendor/bundle/ruby/3.1.0/gems/rack-2.2.7/lib/rack/method_override.rb:24
c:0073 p:0035 s:0528 e:000527 METHOD /app/vendor/bundle/ruby/3.1.0/gems/rack-2.2.7/lib/rack/tempfile_reaper.rb:15
c:0072 p:0007 s:0519 e:000518 METHOD /app/vendor/bundle/ruby/3.1.0/gems/rack-2.2.7/lib/rack/etag.rb:27
c:0071 p:0050 s:0508 e:000507 METHOD /app/vendor/bundle/ruby/3.1.0/gems/rack-2.2.7/lib/rack/conditional_get.rb:27
c:0070 p:0007 s:0499 e:000498 METHOD /app/vendor/bundle/ruby/3.1.0/gems/rack-2.2.7/lib/rack/head.rb:12
c:0069 p:0026 s:0491 e:000490 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_dispatch/http/permissions_policy.rb:22
c:0068 p:0026 s:0481 e:000480 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_dispatch/http/content_security_policy.rb:19
c:0067 p:0026 s:0468 e:000467 METHOD /app/vendor/bundle/ruby/3.1.0/gems/rack-2.2.7/lib/rack/session/abstract/id.rb:266
c:0066 p:0005 s:0457 e:000456 METHOD /app/vendor/bundle/ruby/3.1.0/gems/rack-2.2.7/lib/rack/session/abstract/id.rb:260
c:0065 p:0026 s:0452 e:000451 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_dispatch/middleware/cookies.rb:697
c:0064 p:0008 s:0442 e:000441 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_dispatch/middleware/callbacks.rb:27
c:0063 p:0024 s:0439 e:000438 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activesupport-6.1.7.3/lib/active_support/callbacks.rb:98
c:0062 p:0009 s:0430 e:000429 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_dispatch/middleware/callbacks.rb:26
c:0061 p:0033 s:0423 e:000422 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_dispatch/middleware/actionable_exceptions.rb:18
c:0060 p:0026 s:0417 e:000416 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_dispatch/middleware/debug_exceptions.rb:29
c:0059 p:0026 s:0406 e:000405 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_dispatch/middleware/show_exceptions.rb:33
c:0058 p:0007 s:0399 e:000398 BLOCK  /app/vendor/cache/chewy-de4274461d1b/lib/chewy/railtie.rb:19
c:0057 p:0009 s:0396 e:000395 METHOD /app/vendor/cache/chewy-de4274461d1b/lib/chewy/strategy.rb:70
c:0056 p:0078 s:0390 e:000389 METHOD /app/vendor/cache/chewy-de4274461d1b/lib/chewy.rb:201
c:0055 p:0157 s:0384 E:0015c8 METHOD /app/vendor/cache/chewy-de4274461d1b/lib/chewy/railtie.rb:19
c:0054 p:0040 s:0379 e:000378 METHOD /app/vendor/bundle/ruby/3.1.0/gems/railties-6.1.7.3/lib/rails/rack/logger.rb:37
c:0053 p:0007 s:0369 e:000368 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/railties-6.1.7.3/lib/rails/rack/logger.rb:26
c:0052 p:0003 s:0366 e:000365 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/activesupport-6.1.7.3/lib/active_support/tagged_logging.rb:99
c:0051 p:0012 s:0363 e:000362 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activesupport-6.1.7.3/lib/active_support/tagged_logging.rb:37
c:0050 p:0015 s:0357 e:000356 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activesupport-6.1.7.3/lib/active_support/tagged_logging.rb:99
c:0049 p:0039 s:0351 e:000350 METHOD /app/vendor/bundle/ruby/3.1.0/gems/railties-6.1.7.3/lib/rails/rack/logger.rb:26
c:0048 p:0052 s:0345 e:000344 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_dispatch/middleware/remote_ip.rb:81
c:0047 p:0019 s:0339 e:000338 METHOD /app/vendor/bundle/ruby/3.1.0/gems/request_store-1.5.1/lib/request_store/middleware.rb:19
c:0046 p:0008 s:0330 e:000329 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/rack-timeout-0.6.3/lib/rack/timeout/core.rb:148
c:0045 p:0055 s:0326 E:002690 METHOD /app/vendor/bundle/ruby/3.1.0/gems/rack-timeout-0.6.3/lib/rack/timeout/support/timeout.rb:19
c:0044 p:0425 s:0318 E:000d98 METHOD /app/vendor/bundle/ruby/3.1.0/gems/rack-timeout-0.6.3/lib/rack/timeout/core.rb:147
c:0043 p:0043 s:0301 e:000300 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_dispatch/middleware/request_id.rb:26
c:0042 p:0092 s:0295 e:000294 METHOD /app/vendor/bundle/ruby/3.1.0/gems/rack-2.2.7/lib/rack/method_override.rb:24
c:0041 p:0020 s:0289 e:000288 METHOD /app/vendor/bundle/ruby/3.1.0/gems/rack-2.2.7/lib/rack/runtime.rb:22
c:0040 p:0033 s:0279 e:000278 METHOD /app/vendor/bundle/ruby/3.1.0/gems/activesupport-6.1.7.3/lib/active_support/cache/strategy/local_cache_middleware.rb:29
c:0039 p:0016 s:0272 e:000271 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_dispatch/middleware/executor.rb:14
c:0038 p:0018 s:0264 e:000263 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_dispatch/middleware/static.rb:24
c:0037 p:0007 s:0259 e:000258 METHOD /app/lib/middleware/rack/add_connection_pool_context.rb:11
c:0036 p:0007 s:0254 e:000253 METHOD /app/vendor/bundle/ruby/3.1.0/gems/rack-2.2.7/lib/rack/sendfile.rb:110
c:0035 p:0234 s:0242 e:000241 METHOD /app/vendor/bundle/ruby/3.1.0/gems/rack-cors-1.1.1/lib/rack/cors.rb:100
c:0034 p:0028 s:0228 e:000227 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_dispatch/middleware/ssl.rb:77
c:0033 p:0057 s:0222 e:000221 METHOD /app/vendor/bundle/ruby/3.1.0/gems/actionpack-6.1.7.3/lib/action_dispatch/middleware/host_authorization.rb:148
c:0032 p:0017 s:0216 e:000215 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/honeybadger-5.2.1/lib/honeybadger/rack/error_notifier.rb:33
c:0031 p:0010 s:0210 e:000209 METHOD /app/vendor/bundle/ruby/3.1.0/gems/honeybadger-5.2.1/lib/honeybadger/agent.rb:433
c:0030 p:0008 s:0204 e:000203 METHOD /app/vendor/bundle/ruby/3.1.0/gems/honeybadger-5.2.1/lib/honeybadger/rack/error_notifier.rb:30
c:0029 p:0024 s:0199 e:000198 METHOD /app/vendor/bundle/ruby/3.1.0/gems/honeybadger-5.2.1/lib/honeybadger/rack/user_feedback.rb:31
c:0028 p:0024 s:0189 e:000188 METHOD /app/vendor/bundle/ruby/3.1.0/gems/honeybadger-5.2.1/lib/honeybadger/rack/user_informer.rb:21
c:0027 p:0007 s:0179 e:000178 BLOCK  /app/lib/middleware/rack/tracing.rb:27
c:0026 p:0022 s:0176 e:000175 METHOD /app/vendor/bundle/ruby/3.1.0/gems/opentelemetry-api-1.1.0/lib/opentelemetry/context.rb:104
c:0025 p:0021 s:0169 e:000168 METHOD /app/app/components/operations/telemetry/tracer.rb:20
c:0024 p:0087 s:0163 e:000162 METHOD /app/lib/middleware/rack/tracing.rb:26
c:0023 p:0008 s:0156 e:000155 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/opentelemetry-instrumentation-rack-0.23.0/lib/opentelemetry/instrumentation/rack/middlewares
c:0022 p:0006 s:0153 e:000152 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/opentelemetry-instrumentation-rack-0.23.0/lib/opentelemetry/instrumentation/rack.rb:45
c:0021 p:0024 s:0148 e:000147 METHOD /app/vendor/bundle/ruby/3.1.0/gems/opentelemetry-api-1.1.0/lib/opentelemetry/context.rb:87
c:0020 p:0023 s:0140 e:000139 METHOD /app/vendor/bundle/ruby/3.1.0/gems/opentelemetry-instrumentation-rack-0.23.0/lib/opentelemetry/instrumentation/rack.rb:45
c:0019 p:0022 s:0135 e:000134 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/opentelemetry-instrumentation-rack-0.23.0/lib/opentelemetry/instrumentation/rack/middlewares
c:0018 p:0006 s:0131 e:000130 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/opentelemetry-api-1.1.0/lib/opentelemetry/trace.rb:72
c:0017 p:0024 s:0126 e:000125 METHOD /app/vendor/bundle/ruby/3.1.0/gems/opentelemetry-api-1.1.0/lib/opentelemetry/context.rb:87
c:0016 p:0023 s:0118 e:000117 METHOD /app/vendor/bundle/ruby/3.1.0/gems/opentelemetry-api-1.1.0/lib/opentelemetry/trace.rb:72
c:0015 p:0035 s:0113 e:000112 METHOD /app/vendor/bundle/ruby/3.1.0/gems/opentelemetry-api-1.1.0/lib/opentelemetry/trace/tracer.rb:29
c:0014 p:0053 s:0100 e:000099 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/opentelemetry-instrumentation-rack-0.23.0/lib/opentelemetry/instrumentation/rack/middlewares
c:0013 p:0011 s:0095 e:000094 METHOD /app/vendor/bundle/ruby/3.1.0/gems/opentelemetry-api-1.1.0/lib/opentelemetry/context.rb:71
c:0012 p:0103 s:0089 e:000088 METHOD /app/vendor/bundle/ruby/3.1.0/gems/opentelemetry-instrumentation-rack-0.23.0/lib/opentelemetry/instrumentation/rack/middlewares
c:0011 p:0047 s:0081 e:000080 METHOD /app/vendor/bundle/ruby/3.1.0/gems/hirefire-resource-0.10.1/lib/hirefire/middleware.rb:37
c:0010 p:0016 s:0076 e:000075 METHOD /app/vendor/bundle/ruby/3.1.0/gems/railties-6.1.7.3/lib/rails/engine.rb:539
c:0009 p:0028 s:0070 e:000069 METHOD /app/vendor/bundle/ruby/3.1.0/gems/puma-5.6.5/lib/puma/configuration.rb:252
c:0008 p:0007 s:0065 e:000064 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/puma-5.6.5/lib/puma/request.rb:77
c:0007 p:0022 s:0062 e:000061 METHOD /app/vendor/bundle/ruby/3.1.0/gems/puma-5.6.5/lib/puma/thread_pool.rb:340
c:0006 p:0285 s:0057 e:000056 METHOD /app/vendor/bundle/ruby/3.1.0/gems/puma-5.6.5/lib/puma/request.rb:76
c:0005 p:0111 s:0036 e:000035 METHOD /app/vendor/bundle/ruby/3.1.0/gems/puma-5.6.5/lib/puma/server.rb:443 [FINISH]
c:0004 p:---- s:0024 e:000023 IFUNC
c:0003 p:0097 s:0021 e:000018 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/puma-5.6.5/lib/puma/thread_pool.rb:147
c:0002 p:0045 s:0007 e:000006 BLOCK  /app/vendor/bundle/ruby/3.1.0/gems/logging-2.3.1/lib/logging/diagnostic_context.rb:474 [FINISH]
c:0001 p:---- s:0003 e:000002 (none) [FINISH]
-- Ruby level backtrace information ----------------------------------------
-- Machine register context ------------------------------------------------
 RIP: 0x00007f86a67715ab RBP: 0x00007f869a2eaf80 RSP: 0x00007f869d5e6600
 RAX: 0x0000000000000004 RBX: 0x0000000000000000 RCX: 0x000000000000009e
 RDX: 0x0000000000000130 RDI: 0x000055e53afc0040 RSI: 0x0000000000000030
  R8: 0x0000000000000001  R9: 0x0000000000000020 R10: 0x0000000000000028
 R11: 0x0000000000000028 R12: 0x000055e53afc0040 R13: 0x000000000000000c
 R14: 0x000055e53afc0080 R15: 0x00007f8693ad0608 EFL: 0x0000000000010206
-- C level backtrace information -------------------------------------------

Thanks for opening this issue.
This is our first report of an issue with this patch causing segfaults, the patches are written in Ruby and do not change any of the underlying native extensions so I am surprised to see you all are experiencing this.
Would you be able to disable the instrumentation to confirm the issue is not related to concurrent access of DB connections? https://github.com/ged/ruby-pg/issues/493

We're running pg 1.5.2. I kind of figured the wrappers we're pretty simple and odd to be sprouting this kind of issue.
I will look into disabling this temporarily. Might take a few days to get back / verify the issue persists or goes away.

Thank you. If you have the ability to updating environment variables without requiring code changes, you may consider setting OTEL_RUBY_INSTRUMENTATION_PG_ENABLED to false. The instrumentation will then skip installation when your application picks up the envar changes.

pg-1.5.3 fixes a possible segfault in PG::Connection#exec* methods, when using a type map like rails does. Is it still happening with pg-1.5.3?

Experiencing this with 1.5.3
/Users/victor/.rvm/gems/ruby-3.2.2/gems/pg-1.5.3/lib/pg/connection.rb:690: [BUG] Segmentation fault at 0x00000001054b0aa6

@Amnesthesia your segfault happens in a different line of code. It's probably this issue in Macos: https://github.com/ged/ruby-pg/issues/538

@larskanis Turned out to be libpq not being installed and my pg being built against postgres 13, using Postgres.app with postgres 13, and then having updated brew and having the CLI for postgres 14.8 installed.
Solved by uninstalling pg gem, installing libpq and compiling pg gem with --with-pg-config=... and pointing to the correct version

authors: Amnesthesia arielvalentin larskanis zacheryph