SSSOM: Separate profile for Literal Mappings

as discussed in #197 we are now going to provide a basic spec for a literal mapping. This is the suggestion:

Literals take the place of the "subjects" in the normal sssom
we ditch all of the subject related metadata columns
INCOMPLETE ISSUE DONT READ

Being addressed here #235
@udp is currently in a mad push on OLS, but maybe James, when you get a chance, can you tell me what else needs doing on that PR to call it "good enough" for v1?

cc @rsgoncalves, would also like to hear your input on the PR if you don't mind. Happy to answer any questions if you don't understand what exactly it does!

The PR looks good to me. I think we can swap out our (simple) mapping format with SSSOM straightforwardly. I could use your help clarifying a few things, further below.
For others reading this, perhaps missing some context: In the mapping tool  we've been developing, the output is a simple table like so: (subject_id, subject_label, object_id, object_label, mapping_score). For example: ("bbj-a-113", "Endometrial cancer", "http://www.ebi.ac.uk/efo/EFO_1001512", "endometrial carcinoma", 0.977010419). The tool doesn't output a predicate but it is assumed to be exactMatch— through UIs, curators can change the predicate to 'broad' or 'narrow'.
Now to questions:

In mapping some literals, like trait descriptions in OpenGWAS database records, we want to keep track of the (internal) record identifier associated with each literal. Would it be possible to keep some subject metadata as optional? I understand these identifiers are not of general use, but they're used in internal pipelines and this way we wouldn't have to maintain 2 tables (an internal identifier table + a SSSOM table).

The description of literal_source states "URI of ontology source for the literal". Seems there's an assumption these literals come from ontologies— is this intended? Do values need to resolve? If not, I imagine this field could be (ab)used to store internal identifiers, for example, but not sure that's the appropriate use.

What is the design difference between confidence and similarity_score (when to use one vs the other)? We output a mapping "confidence" score, which is a similarity score computed by one of multiple supported similarity metrics.

I think literal_source may be confused with being the context (text, database, etc) from which the literal originated, but it may be an option - I am 50/50 here. However, to avoid marketing issues moving forward: can you articulate a bit more how we can communicate the difference between:
Classic SSSOM:

subject_id
subject_label
predicate_id
object_id
object_label
mapping_justification

A:1
label 1
skos:exactMatch
A:2
label 2
semapv:LexicalMatching

Literal Profile

literal_source
literal
predicate_id
object_id
object_label
mapping_justification

A:1
label 1
skos:exactMatch
A:2
label 2
semapv:LexicalMatching

I see I approved #235 but I actually have a number of problems to raise

I thought this was going to be a separate profile, not go in the main schema
Currently this is causing some issues as we are reusing the same slot_uri for different meanings in literal and non literal mappings (some of these can be fixed in linkml but you will run into issues with jsonld)
don't use spaces in class names
I also pointed out overlap with annotation models
How are these to be used, exchanged, serialized? How are they collected? Will a MappingSet be extended to allow separate fields for literal mappings and mappings? (and how would this work e.g. with CSV)? Perhaps the range of mappings will be extended to be a union of mapping and literal mapping? Or will these be a separate LiteralMappingSet?

don't use spaces in class names

I see many models that do this, like https://github.com/biolink/biolink-model/blob/1698cf997785490304a617123d5e3a242c6b2bc0/biolink-model.yaml#L6128. Where can I find focs about this?

I thought this was going to be a separate profile, not go in the main schema

Is there something to read about modular schema development best practices?

Currently this is causing some issues as we are reusing the same slot_uri for different meanings in literal and non literal mappings (some of these can be fixed in linkml but you will run into issues with jsonld)

That was an honest mistake, now fixed. Technically literal mappings are not yet connected to the spec, we just wanted to have the docs out there to be able to use it, even if there is no tool support.

Technically literal mappings are not yet connected to the spec, we just wanted to have the docs out there to be able to use it, even if there is no tool support.

But how is the “literal profile” even supposed to be used? All we have is a literal mapping class which cannot be contained in a mapping set (a mapping set can only contains mapping, not literal mapping).
I second @cmungall ’s questions:

How are these to be used, exchanged, serialized? How are they collected? Will a MappingSet be extended to allow separate fields for literal mappings and mappings? (and how would this work e.g. with CSV)? Perhaps the range of mappings will be extended to be a union of mapping and literal mapping? Or will these be a separate LiteralMappingSet?

Those questions should get answered before we make a SSSOM 1.0, or the “literal profile” should be removed from the 1.0 version in my opinion.

I think a separate literal mapping set would be fine? It was never the intention that they would be in the same file.
The use case for this is to publish all of the manually asserted string to term mappings we have collected in ZOOMA, see https://github.com/EBISPOT/zooma2sssom/tree/master/mappings

I don’t see why we even need a separate “profile” or a separate class for literal mappings for such a use case.
Why not simply put the literal in the subject_label? Along with a new EntityType value for subject_type that indicates that the subject is a literal and that, therefore, for this particular mapping it is the subject_label, not the subject_id, that matters (the subject_id can even be absent).
subject_label	predicate_id	object_id	mapping_justification	mapping_provider	subject_type
uterus	http://www.w3.org/2000/01/rdf-schema#label	http://purl.obolibrary.org/obo/BTO_0001424	https://w3id.org/semapv/vocab/ManualMappingCuration	https://www.ebi.ac.uk/vg/faang	literal
sperm	http://www.w3.org/2000/01/rdf-schema#label	http://purl.obolibrary.org/obo/CL_0000019	https://w3id.org/semapv/vocab/ManualMappingCuration	https://www.ebi.ac.uk/vg/faang	literal
kidney	http://www.w3.org/2000/01/rdf-schema#label	http://purl.obolibrary.org/obo/BTO_0000671	https://w3id.org/semapv/vocab/ManualMappingCuration	https://www.ebi.ac.uk/vg/faang	literal

Yes, I think this approach would work if subject_id is made optional.

I think it's helpful to have an SSSOM-like approach for literals and I agree it fits well and doesn't necessarily need a separate "profile" but I wonder if it would lead to significant scope creep. Could SSSOM become a TSV format for annotating information about any kind of subject-predicate-object relationship? The more slots become optional and optional slots exist, the more developers will have trouble implementing tools and users trouble finding a tool that does what they are looking for.
Why does the literal slot replace the subject_id slot instead of the object_id slot? Would literals ever be able to use oboInOwl synonym predicates? I can't see how oio:hasNarrowSynonym makes sense with a URI as the object. I imagine having the literal as subject works fine with existing mapping predicates (e.g. skos).

Okay, I understand why an official "fork" for literals is desirable and your argument in 3 for adapting the model by adding literal to the list of possible values for subject_type and object_type.
It looks to me like rdfs:Literal is already an option for these type slots (https://mapping-commons.github.io/sssom/EntityTypeEnum/). Correct me if I read the LinkML documentation wrong.
Has anyone tried mixing different types in the same mappingSet?
On the one hand, it would be really convenient for me to curate both a mapping between entities, and a mapping between an entity and literal in a single TSV file like this (top = literal to owl:Class, bottom = owl:Class to owl:Class):

subject_id
subject_label
predicate_id
predicate_modifier
object_id
object_label
mapping_justification
subject_type
object_type

MESH:C535731
Chmrq1
oboInOwl:hasExactSynonym
Not
DOID:0070556
CAMRQ1
semapv:ManualMappingCuration
literal
linkml:Uriorcurie

MESH:C535731
Dysequilibrium syndrome
skos:exactMatch

DOID:0070556
CAMRQ1
semapv:ManualMappingCuration
linkml:Uriorcurie
linkml:Uriorcurie

I assume subject_id would be equivalent to literal_source in https://github.com/mapping-commons/sssom/pull/235.
I can fairly easily tell which is which with just these two mappings, primarily by the predicate I chose to use. But if both mappings used skos:exactMatch as predicate, which I assume would be in spec, it would require a curator to look at the subject_type and object_type slot for every mapping to make sure they are curating the right slots. Having to look that up for every mapping would be much less simple than it is currently, especially when labels become longer and looking at types adds the need for lots of horizontal scrolling.

A “profile” could simply be a list of slots that, within the profile, should be considered mandatory. The spec could define a few of such profiles, and users could be free of defining their own.

I like this idea for a "profile".
It seems fairly straightforward to say in the standard mappings "profile" subject_id, predicate_id, object_id, and mapping_justification are required, while for the literal "profile" subject_label would become required and subject_id optional with no other changes to slots.
Profiles like this could be defined in the mappingSet metadata. Curators could be alerted that everything in a set is of a particular type (or set of allowed types), preventing the confusion I mentioned above. It does lose some of the convenience of creating mappings between very different types in the same file. I suppose you could always define a super "profile" that allows anything from the other defined profiles and then create tools to merge or split profiles.

It looks to me like rdfs:Literal is already an option for these type slots (https://mapping-commons.github.io/sssom/EntityTypeEnum/).

Yes. However it’s unclear to me whether it is suitable here (the poor documentation of the model doesn’t help). Can it be used outside of a RDF context? If I have a list of, say, scRNAseq cell cluster names and I want them to map them to Cell Ontology IDs, would it be correct to use rdfs literal as the subject_type even though the subjects are just entries in a flat list and are not part of any RDF graph at all?
Maybe it would be fine, maybe not. I just don’t know. Whoever came up with the values for the EntityType enum would need to clarify.

Has anyone tried mixing different types in the same mappingSet?

Do you mean, mixing mappings with different subject_type (or object_type) values? I never had to do that (all the mappings I have to deal with are mappings between OWL classes), but that’s a completely supported situation. I don’t know for SSSOM-Py, but SSSOM-Java would have no problem whatsoever dealing with such mixed mappings.
Or did you mean, mixing (normal) mappings with literal mappings (as represented by the new profile)? Then no, right now it’s completely impossible to do that.

On the one hand, it would be really convenient for me to curate both a mapping between entities, and a mapping between an entity and literal in a single TSV file like this (top = literal to owl:Class, bottom = owl:Class to owl:Class):
subject_id	subject_label	predicate_id	predicate_modifier	object_id	object_label	mapping_justification	subject_type	object_type
MESH:C535731	Chmrq1	oboInOwl:hasExactSynonym	Not	DOID:0070556	CAMRQ1	semapv:ManualMappingCuration	literal	linkml:Uriorcurie
MESH:C535731	Dysequilibrium syndrome	skos:exactMatch	 	DOID:0070556	CAMRQ1	semapv:ManualMappingCuration	linkml:Uriorcurie	linkml:Uriorcurie

I am sorry but I don’t understand your example at all.
The second mapping states that DOID:0070556 is an exact match to MESH:C535731; the first one seems to state that DOID:0070556 is not an exact synonym to MESH:C535731. I don’t understand what is that supposed to mean. Why does MESH:C535731 have a different label in the two mappings? Why is the subject_type of the first mapping a literal, while it clearly refers to an entity?
(Besides, linkml:Uriorcurie is not a valid value for subject_ or object_type.)

I can fairly easily tell which is which with just these two mappings, primarily by the predicate I chose to use. But if both mappings used skos:exactMatch as predicate, which I assume would be in spec

Again, I don’t understand what you mean here. The spec does not and will not mandate which predicate to use (at most it can recommend that some predicates be used or conversely discourage the use of some others, but that’s it). Just because “literal mappings” would become an officially supported type of mapping does not mean that the spec would force you to use skos:exactMatch for those mappings.

It seems fairly straightforward to say in the standard mappings "profile" subject_id, predicate_id, object_id, and mapping_justification are required, while for the literal "profile" subject_label would become required and subject_id optional with no other changes to slots.

Something like that, yes.

Profiles like this could be defined in the mappingSet metadata.

I would not envision allowing the definition of a profile in a mapping set’s metadata. Instead, profiles should be defined externally, and a mapping set would simply declare that they use a specific profile. Allowing each mapping set to define its own profile seems like a needless complication to me.

Curators could be alerted that everything in a set is of a particular type

You don’t need profiles to do that. subject_type and object_type are propagatable slots, which means that if all mappings in your set have the same subject_type (resp. object_type), you can set the subject_type (resp. object_type) once and for all in the mapping set’s metadata and the value you set there will apply to all mappings in the set.

I suppose you could always define a super "profile" that allows anything from the other defined profiles

Or you can just not use profiles, if you need to merge several sets that are compliant to different profiles. Profiles, if we ever create them, would not be a mandatory feature – mapping sets would not have to have to a profile.

Sorry for barging in here, I dont have time to comment on here much. Here is my very short take:

Literal mappings and semantic entity mappings are very different things and should not be confused
We have had lots of meetings about the literal profile and its motivation, discussed it at a workshop, had a PR open for months (or years) and it is done. I will take an unusually hard stance against pulling it back (not unbreakable, but hard, so it will be a big distraction for all of us).
The main use case is to capture grounding decisions ("string occurrences in text that are supposed to refer to a concept"), sort of like a synonym table. I am very against mixing the concepts of synonyms and mappings.
I dont not think we should make our work of maintaining SSSOM core model harder by considering what the status is of the profile(s, in the future). Lets just label them as "inoffical", not part of the main standard, for now.

Literal mappings and semantic entity mappings are very different things and should not be confused

OK.

We have had lots of meetings about the literal profile and its motivation, discussed it at a workshop, had a PR open for months (or years)

Where is the trace of those “lots of meetings”?
All I know about is:

the discussion in #197, which has not been a particularly active one and which provides very few insights about how you came to the current “design” – in fact, according to that discussion most of the decisions were taken in what seems to have been a private discussion between you and @udp, the minutes of which are not available anywhere;

this #234 issue, which was open at a time the decision to go for a separate “literal profile” had already been taken;

the “2nd Mapping Commons Workship on SSSOM”, which included a presentation by James about the literal profile – again, at a time the decision to use a separate profile for literal mappings had already been taken; if the correctness of that decision has been discussed in that workshop after James’ presentation, where are the minutes?

it is done

We have a very opinion of what can be considered “done”. I say it again: the literal profile is right now unusable. There are ways too many questions left open about how it can/should be used.
The only thing the literal profile does for now is causing confusion, by leading people to believe they can use SSSOM to represent literal mappings, which is absolutely not the case.
The EBI has already started to publish “literal mapping sets” (see James’ message above) in .sssom.tsv files. Anyone could legitimately conclude that those files are bona fide SSSOM/TSV files, and therefore would expect to be able to use them with the existing SSSOM/TSV tools. But those files are not SSSOM/TSV files – no SSSOM tools can deal with them! And no SSSOM tools will ever be able to deal with them.
Aren’t we suppose to care about “interoperability”?

I am very against mixing the concepts of synonyms and mappings.

OK.

I dont not think we should make our work of maintaining SSSOM core model harder by considering what the status is of the profile(s, in the future). Lets just label them as "inoffical", not part of the main standard, for now.

Hard disagree. You’re taking the easy path now without consideration for how hard you will make things in the future. That may be fine for software development in general (“move fast and break things”, as the tech bros of Silicon Valley are saying), but for when desiging a (hopefully) long-term standard.
Right now, the “literal profile” is a half-assed design that no one knows how to use (not even you apparently). Leaving it like that and kicking the can down the road can only come back to hit us hard in the future.

@goutteg, confusion caused by the example table I shared is exactly the point I was trying to make about mixing literal and entity mappings. The source of both mappings is the same MESH entity, but the top mapping is between the literal in the subject_label (which was a synonym linked to that MESH term) and states that that literal should NOT be mapped to the specified DOID because it is wrong, while the bottom mapping is between the MESH and DOID entities and states they are exact matches. I could have left out the subject_id for the top mapping because it is optional but I wanted to be able to tell in the future where this literal came from.
@matentzn, barging in... hahaha. Like you said, you put in work earlier when you had time. I'm sorry I couldn't contribute more at an earlier stage, but I'm fine with leaving literals as unofficial. Can I ask why rdfs:Literal is an option for subject_type, predicate_type and object_type in SSSOM?

A somewhat naive comment (it's hard to keep all these arguments clear without spending many hours, I thank you who have devoted that time):

Can someone easily describe the use case for literals in a mapping? I don't understand what they mean conceptually, especially when the location of the string is not captured (true?), and why the word "mapping" applies. I think I've read all the discussion but I haven't seen that crisply captured; a pointer is fine if I'm wrong.
I know I've read the justification for liberals as subjects and I really don't understand that. It may be too sophisticated for my ontology expertise, you don't have have to spend time on just me (but others like me will eventually use it, or try to).

WIth that in mind, I still think these basic thoughts could apply:

It is very non-ideal to have literals allowed by one part of the standard but not enabled by the other parts. Given that, the 'doneness' of the previous decision is not matched by the specification, so a decision needs to be taken.
If it is possible to make literals enabled with a minimal amount of work, I think that is worth doing, because it adds a lot of value. It seems to me literals only as objects makes the most sense as a minimal amount of work.
If it is not possible to enable literals with minimal work, remove the other reference(s) to them and stop here.
Even if mixing literals in the same spec/the same mapping is heresy for some reason, I think if they are to be supported at all then creating a whole separate profile is unhelpfully complicating for many users who want to do that. Because, usability.

I agree that if literals are not crisply specified in this standard, the chance of divergence and even competing standards is high. But if you think literal-included triples are not really mappings for SSSOM, then that's the principled decision on which you should stand, and that other thing is not a profile, it's a different standard.

Implementing literal mapping to me is achieving the final step to make SSSOM a duplicata of RDF (and even RDF-star as we can say things about the triple). I don't think we need another RDF.
This is exactly what the example just above shows.
You can drop the Simple, yo can change Ontology by Resource and you get SSRM.

In the interest of driving SSSOM 1.0 home in the coming weeks and the enormous amount of things to unpack in all the comments given here, I am ok with yanking the literal profile from the standard, for now (not happy but I can read a room 😂). I can move it to another repo and develop it independently as a non-Standard, and make sure we communicate use cases clearly for this. One day in the far future we can move this "profile" or "standard for something else" back here and have a vote.
Please voice your objections to this approach until 1st August; I will be responsible for the move!

I am ok with yanking the literal profile from the standard, for now
[…]
One day in the far future we can move this "profile" or "standard for something else" back here

This is just another version of “kicking the can down the road”, only in a different repo.
If the intention is that at some point the “literal mapping” becomes a part of SSSOM, we should think about how this will be done right now.
Adding in the future a new class of mappings is a completely different beast than adding or removing a slot in the existing mapping class.
For now, all the code dealing with SSSOM (in Python, Java, or any other language) can be built around the assumption that there is only one class of mapping. This is not something that will be easy to change, and the longer that assumption stays around, the harder it will be to change.
So if you already know that at some point you want the standard (and its implementations) to deal with several types of mappings (e.g mapping and literal mapping), this is something that must be decided ASAP, not “sometimes in the future”.

Hi, typing from my phone as I’m away for the weekend without access to a computer. For us (biocurators at EBI) mapping from term to term or string to term are both classes of the same problem. We often have datasets that require both types of mappings to get to the types of identifiers we want. For example I am currently working with a dataset that has a mix of chemical names and CAS numbers. I want to map the CAS number where available (obviously a use case for core SSSOM) and otherwise map the chemical name (literal mapping). This is perhaps not the best example but I can dig out unlimited more when I get back to the office.
At EBI we use two tools for these term and literal mappings respectively: OXO and ZOOMA. So far we have maintained the databases for these tools internally which is not in the FAIR spirit of our community. We are therefore opening up OXO using SSSOM and hope to do the same with ZOOMA.
Just like term mappings, literal mappings are context dependent (we maintain different literal mapping sets per project in zooma for this reason) and have metadata associated eg lexical match or manual curation, a mapping author, a date, etc etc. I don’t think solving these problems twice by making a new SSSLiteralOM complete with website, issue tracker and so on is the best way to spend our time when we already have the community mindshare (or so I thought) and infrastructure here to support it
In fact this is extremely unlikely to happen with the resources we have, so ZOOMA’s data would stay loosely specified and difficult to use - but I thought we left this like of thing in the past and moved towards trying to agree on things to enable interoperability.

@jamesamcl I am not against representing literal mappings in SSSOM.
I do share a bit of @jonquet ’s concerns about re-inventing RDF, but from what I’ve seen in the wild I am afraid that horse has left the barn anyway: people have already started to use SSSOM/TSV to serialise arbitrary RDF triples and not only triples that represent “mappings”. (This is a concern that has already been mentioned in #324). This is not what SSSOM is intended for, but I don’t think there’s much we can do about it. Once you put a tool in people’s hands, they will use it in any way they like. A kitchen knife is not supposed to be used to turn screws, but people will use one for that purpose if they don’t have a screwdriver. So what? I don’t think we should prevent SSSOM from being useful to manipulate mappings just because people find it useful to do other things with it (including things they shouldn’t do).
But if we are to allow literal mappings to be represented in SSSOM, we should do so correctly, and I am sorry but #235 is not a correct solution in its current state.
I see two ways of representing literal mappings in SSSOM:
A) Having a separate literal mapping class. That’s what #235 is about, but it does it in way that leaves way too many questions open.
If we want to go that route, I will insist that these questions must be addressed ASAP, before SSSOM 1.0 is published, because as I have stated above, this route breaks the assumption that there is only one class of mapping. That assumption has been there since the beginning of SSSOM, and is still present everywhere in the current form of the standard even after #235 has been merged.
In particular, the MappingSet class (which is the basis for the SSSOM/TSV format, since a SSSOM/TSV file is basically a serialisation of a MappingSet object) can only contain Mapping objects, not LiteralMapping objects.
So if we now have to deal with more classes of mappings than just Mapping, how are we going to do that?

Keep MappingSet as containing only Mapping objects, and have a separate LiteralMappingSet class to contain LiteralMapping object?
Add a literal_mappings slot to MappingSet?
Make LiteralMapping a subclass of Mapping, so we can keep MappingSet unchanged?
Make the mappings slots of MappingSet accept indifferently a list of Mapping or a list of LiteralMapping?
Other ideas?

Whatever method we choose is going to have huge implications on SSSOM implementations (especially implementations in statically typed languages), so I am flatly opposed to postponing any decision on this to after 1.0. I don’t care if this means that 1.0 is going to be delayed by 10 months until we figure out how to do it.
B) Shoehorn literal mappings into the existing Mapping class. That is basically what I proposed in point (3) of this comment. We don’t create a new class, but we define a way to use it to represent literal mappings.
That would be a much less invasive change, with much less implications on implementations, because the assumption that there will only ever be one class of mapping would stand. For that reason: (1) I tend to favor that route; (2) if we want to go that route we can easily postpone that to after 1.0.

Alright, here we go.
#384 introduces an alternative model to the "literal mapping" proposal we have previously added. It is built on the following assumptions:

Introducing a profile causes a needless overhead which requires specialised tooling
We can achieve the same functionality with a very minimal intervention in the main SSSOM metadata model (see various @gouttegd comments above)

I do understand that there are various opposing views on the need for a "literal" profile, but I think this super minimal intervention will satisfy both sides. In essence, we do not have a literal profile; we have a convention that allows us to represent an "entity" by its label (subject_label) rather than by a semantic identifier. This means we do not need specialised tooling and documentation (nor training).
Huge thanks to @gouttegd 🙏  who managed to steer this massive carrier ship after it had left the harbor. This is rarely successful and needed a huge amount of thought, testing, and patience (mostly with me and my constant questions), and I am supremely happy we managed to make it!
🎉  THAT WAS IT FOLKS - the last issue before SSSOM 1.0 (#189). Thanks to all of you who helped and contributed; now the carrier ship has sailed off the horizon, hopefully, to connect the isolated shores of our data islands!

For those who had started to create pseudo-SSSOM/TSV files using the “literal profile” (even though this has never been officially feasible since that profile had never been connected to the rest of the spec), SSSOM-Java will support reading such files and converting it them to the new proposed convention.
That is, given an input file like this:
#curie_map:
#  some: https://example.org/my_source_of_literals
#  BTO: http://purl.obolibrary.org/obo/BTO_
#  CL: http://purl.obolibrary.org/obo/CL_
#mapping_set_id: https://example.org/myset
literal   literal_source   predicate_id      object_id     mapping_justification
uterus    some:source      skos:exactMatch   BTO:0001424   semapv:ManualMappingCuration
sperm     some:source      skos:exactMatch   CL:0000019    semapv:ManualMappingCuration
kidney    some:source      skos:exactMatch   BTO:0000671   semapv:ManualMappingCuration

SSSOM-CLI will silently convert it into:
#curie_map:
#  BTO: http://purl.obolibrary.org/obo/BTO_
#  CL: http://purl.obolibrary.org/obo/CL_
#  some: https://example.org/my_source_of_literals
#mapping_set_id: https://example.org/myset
#license: https://w3id.org/sssom/license/all-rights-reserved
#subject_type: rdfs literal
#subject_source: some:source
subject_label   predicate_id      object_id       mapping_justification
kidney          skos:exactMatch   BTO:0000671     semapv:ManualMappingCuration
sperm           skos:exactMatch   CL:0000019      semapv:ManualMappingCuration
uterus          skos:exactMatch   BTO:0001424     semapv:ManualMappingCuration


Add enable/disable system for testplugins

/test enable|disable <plugin1> <plugin2>
/test status

TestPlugins are disabled by default.

Just maybe squash commits prior to merging.


NavigationView documentation is outdated.

Describe the bug
https://github.com/microsoft/microsoft-ui-xaml/blob/dfbe38bfb2996dfaa2f09544c4e86aa69ccc906b/dev/NavigationView/docs/rendering.md
This document says that 'SettingsNavPaneItem' is part of the templated controls. However, I think recent changes in the control made this templated part to be moved somewhere dynamic. Potentially Pane Footer area.

Steps to reproduce the bug

Steps to reproduce the behavior:

Try to retrieve this templated part of the control in OnApplyTemplate

Expected behavior
Settings button's NavigationViewItem is returned.
Screenshots

Version Info

NuGet package version:
Microsoft.UI.Xaml 2.5.0
Bug doesn't occur on version 2.4.0. So the documentation is valid for 2.4.0

Windows app type:

UWP
Win32

Yes
Unknown (Potentially yes)

Windows 10 version
Saw the problem?

Insider Build (xxxxx)

May 2020 Update (19041)

November 2019 Update (18363)
Yes

May 2019 Update (18362)

October 2018 Update (17763)

April 2018 Update (17134)

Fall Creators Update (16299)

Creators Update (15063)

Device form factor
Saw the problem?

Desktop
Yes

Xbox

Surface Hub

IoT

Additional context
This bug is related to documentation itself. However, not sure if fixing the documentation or fixing the actual code and re-name the element as 'SettingsNavPaneItem' should be done. GetTemplateChild might not work for dynamically generated content in OnApplyTempalte call. Therefore, fixing this on the code itself can be challenging.

@chingucoding You authored that doc, right? Would you like to update it?

Sure! Feel free to assign me to the issue.


[v2] Add/remove calendar events dynamically

@nolimits4web
Could you please add a method to add and remove calendar events dynamically if it is already initialized?

It is already there calendar.update() method will rerender currently opened/visible calendar

@nolimits4web
Thank you very much!

Hi~
Does calendar.update() method still work?

calendar.update() does not seem to redraw the Event Dots under the Days. I have the calendar.update() in the Calendar's init() after the calendar.events has been populated with data...? Any ideas?


[CELEBORN-1763] Fix DataPusher be blocked for a long time

What changes were proposed in this pull request?
fix DataPusher be blocked for a long time
Why are the changes needed?
The worker has been at a performance bottleneck for a long time, the slow start strategy adjusts its maxInFlight to 1, which may cause RequestInFlight to exceed maxInFlight. If the task’s main thread has been blocked in the waitIdleQueueFullWithLock call, then the main thread will not be able to detect the sending failure since this failure changes the exception in the push state, and the waitIdleQueueFullWithLock function does not check for it
Does this PR introduce any user-facing change?
NO
How was this patch tested?
GA

thanks, merged to main/branch-0.5 and branch-0.4


Add support for npm v9

Description

Closes: #1136
How Has This Been Tested?

Create a new build with make build and push it to your registry
Deploy that version to your cluster with make deploy
Check that the build is working fine

Test Impact

Estructural change, you can test it installing quay.io/lferrnan/odh-dashboard:bump-npm-version
Request review criteria:

[X] The commits have meaningful messages (squashes happen on merge by the bot).
[ ] Included any necessary screenshots or gifs if it was a UI change.
[ ] Included tags to the UX team if it was a UI/UX change.
[X] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[X] The developer has manually tested the changes and verified that the changes work
[X] The developer has added tests or explained why testing cannot be added (unit tests & storybook for related changes)

@LaVLaS @andrewballantyne The changes are working just fine downstream, should we test this with the openshift CI just in case?

@LaVLaS @andrewballantyne The changes are working just fine downstream, should we test this with the openshift CI just in case?

If testing in openshift-ci is a reference to #1123 then I think an local test of the prebuilt image should be sufficient as a smoke test since there were scenarios where the error was reproducible locally but not in openshift-ci

quay.io/lferrnan/odh-dashboard:bump-npm-version

Ok, so I've tested the changes here: quay.io/lferrnan/odh-dashboard:bump-npm-version and it seems to be working locally just fine, I'm gonna test right now to install quay.io/opendatahub/odh-dashboard:pr-1392 just to verify if it's working, I'll update both the changes and the status of those tests asap

Tested and working with quay.io/opendatahub/odh-dashboard:pr-1392 it should be ready to go!
@Gkrumbach07 @DaoDaoNoCode @andrewballantyne @LaVLaS We can check this and merge it now

Tested and working with quay.io/opendatahub/odh-dashboard:pr-1392 it should be ready to go!
@Gkrumbach07 @DaoDaoNoCode @andrewballantyne @LaVLaS We can check this and merge it now

As far as I recall -- this has never been a problem upstream in ODH -- we have only ever had issues with the build system in RHODS due to the artifacts it is built with.

Tested and working with quay.io/opendatahub/odh-dashboard:pr-1392 it should be ready to go!
@Gkrumbach07 @DaoDaoNoCode @andrewballantyne @LaVLaS We can check this and merge it now

As far as I recall -- this has never been a problem upstream in ODH -- we have only ever had issues with the build system in RHODS due to the artifacts it is built with.

@andrewballantyne  We had a problem with the latest ubi8 image, mainly due to caching issues in the odh CI/CD pipeline, that's why we had some releases blocked a few weeks ago.
I've tested both a local image and the one built by openshift, it should work fine now.


Add a mention to the AUR

Hi ! After installing from the AUR (as I do for most of my packages) I saw that the command wasn't bat by default but "bat-asus-battery". I modified a bit the readme to include a mention to it and a link to the part of the arch wiki that mentions this package

Hi! Thank you for the pull request and the effort to document the AUR package. However, I am going to close it for now. I prefer to keep the README distribution-agnostic since Linux packaging is complex and varies widely, and would rather have that handled by the package maintainers if they decide to package this application.

This topic could be suitable in the Discussions section somewhere.

A general discussion about packaging or about whether or not should we include packaging information in the README or Wiki?


laravel_session not storing automatically in any brower's local storage

Laravel Version: 5.3.15
PHP Version: 7.0.2
Database Driver & Version: MySql
Machine: Windows 8.1

Description:
When I make a login or registration request, typically the laravel_session cookie is suppose to get returned by laravel and get stored into the browser's local storage.
The project being worked on is using laravel 5.3 as the back-end and communicating with the database. Where as the front-end we're using the angular framework running on the ionic platform. The other people on the project are using iOS computers where as I am on a Windows machine. Their browsers ALL return the proper responses and the laravel_session cookie goes into their local storage by default. Where as mine does not. This makes it difficult to make proper api requests to the server and test things out on my end. We're all on the same commit and using the same code. Is there something that I may have missed on my machine that could be preventing laravel's laravel_session cookie from storing on the front-end browser by default? It get's returned in the Network Tab's response as:
"Set-Cookie=laravel_Session=a9f8eaw9foiawhefao9fia23fi2onaaan3oa2no2fno233f"
however do we need to explicitly set it in the local storage for other machines vs. iOS doing it by default?

It should work normally, need to see how your authorization middleware are set. You say you use angular as a frontend then I assume you use the API auth right?
Please share more "technical" information about the issue.

We currently have it set up right after a fresh install of Laravel 5.3. As for the angular, we haven't even been able to get to hitting the api routes because on my machine the laravel_session cookie isn't being stored in the local_storage when receiving the browser response:
Local Storage In Application Tab

Network Tab on login

This is where some of my code is at:
routes\web.php
`
Route::get('/', function() {
return View::make('index'); // app/views/index.php
});
Auth::routes();
`
App\Http\Kernel.php
VerifyCsrfToken and CreateFreshApiToken have been disabled based on our specific needs.
'web' => [             \App\Http\Middleware\EncryptCookies::class,             \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,             \Illuminate\Session\Middleware\StartSession::class,             \Illuminate\View\Middleware\ShareErrorsFromSession::class,             //\App\Http\Middleware\VerifyCsrfToken::class,             \Illuminate\Routing\Middleware\SubstituteBindings::class,             //\Laravel\Passport\Http\Middleware\CreateFreshApiToken::class, <-- For JWTs on every request         ], protected $routeMiddleware = [         'auth' => \Illuminate\Auth\Middleware\Authenticate::class,         'auth.basic' => \Illuminate\Auth\Middleware\AuthenticateWithBasicAuth::class,         'bindings' => \Illuminate\Routing\Middleware\SubstituteBindings::class,         'can' => \Illuminate\Auth\Middleware\Authorize::class,         'guest' => \App\Http\Middleware\RedirectIfAuthenticated::class,         'throttle' => \Illuminate\Routing\Middleware\ThrottleRequests::class,         'csrf' => \App\Http\Middleware\VerifyCsrfToken::class,     ];
I've cleared my cookies, my history, my cache enabled all cookies from everywhere and even reinstalled chrome and nothing has worked.

After further testing I'm fairly certain that this is a browser issue with my machine regarding cookies and how the browser interacts with them. I'm not exactly sure what changed and when.
If I use Postman with Postman Interceptor I get all proper responses and cookies. However because I cannot use the browser to run full tests I'm kind-a at a loss. Unless I fully erase everything except windows explorer .. (shudders) and re-download all browsers all over again.

When I make a login or registration request, typically the laravel_session cookie is suppose to get returned by laravel and get stored into the browser's local storage.

This is incorrect. Local storage and cookies are two completely different mechanisms. Local storage is something only available to Javascript afaik. You cannot return a response to the browser that then stores something in local storage.
You are looking at the wrong item in the chrome developer tools sidebar. You should be looking under the "Cookies" section.

Closing this then since it's not a bug in the framework, please use the forums where you can find help with your problem :)


Getting Error - Unable to Retrieve Child Resources

Storage Explorer Version:  1.10.1 1.10.1
Build Number:  Build 20190919
Platform/OS:  Windows 10
Architecture:  x64
Regression From:   Intermittennt issue with previous version also.  Could be user error but cant get anywhere.
Bug Description

Can't get the blob resource to show in the explorer.
Can't see any of the resources below the blob, file, queue, Table containers.
Steps to Reproduce

I have tried clearing my credentials and logging in in everyway possible
Expected Experience

Allow me to browse and add folders and upload files.
Actual Experience

No frame appears for those activities to be performed
Additional Context

Help please

Have you tried to go through the Storage Explorer Troubleshooting Guide?  https://docs.microsoft.com/en-us/azure/storage/common/storage-explorer-troubleshooting?tabs=Windows%2C1904
Also, are you behind a proxy server?  If you do, you need to configure the proxy settings.

Closing due to lack of response.


docs: Update sample InputFileDefault.razor

Pull Request
📖 Description
Once I'd started using this component, I simply copied and pasted this first sample. My existing code that uses Stream and of course it didn't work straight away. But after some research I realized that the InputFileMode property is SaveToTemporaryFolder, by default and this attribute is not added. I think the documentation would be clearer if this parameter were specified in this samples
🎫 Issues

👩💻 Reviewer Notes

✅ Checklist
General

[ ] I have added tests for my changes.
[x] I have tested my changes.
[ ] I have updated the project documentation to reflect my changes.
[x] I have read the CONTRIBUTING documentation and followed the standards for this project.

Component-specific

[ ] I have added a new component
[ ] I have added Unit Tests for my new compontent
[ ] I have modified an existing component
[ ] I have validate Unit Tests for an existing component

@microsoft-github-policy-service agree


libsForQt5.kpmcore: 23.04.1 -> 23.08.3

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/kpmcore/versions.
meta.description for libsForQt5.kpmcore is: KDE Partition Manager core library
meta.homepage for libsForQt5.kpmcore is: https://invent.kde.org/system/kpmcore
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 23.04.2 with grep in /nix/store/y474lm0jv1zw8c6qpf17aq5clhzjffzc-kpmcore-23.04.2
found 23.04.2 in filename of file in /nix/store/y474lm0jv1zw8c6qpf17aq5clhzjffzc-kpmcore-23.04.2

Rebuild report (if merged into master) (click to expand)

5 total rebuild path(s)

5 package rebuild(s)

First fifty rebuilds by attrpath
calamares
calamares-nixos
libsForQt5.kpmcore
partition-manager
plasma5Packages.kpmcore

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/y474lm0jv1zw8c6qpf17aq5clhzjffzc-kpmcore-23.04.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A libsForQt5.kpmcore https://github.com/r-ryantm/nixpkgs/archive/22585386ac748d1e6fd2dc72ffdebd0f08afae1f.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/y474lm0jv1zw8c6qpf17aq5clhzjffzc-kpmcore-23.04.2
ls -la /nix/store/y474lm0jv1zw8c6qpf17aq5clhzjffzc-kpmcore-23.04.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

4 packages built:

calamares
calamares-nixos
libsForQt5.kpmcore
partition-manager

Maintainer pings
cc @peterhoeg @oxalica for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/kpmcore/versions.
meta.description for libsForQt5.kpmcore is: KDE Partition Manager core library
meta.homepage for libsForQt5.kpmcore is: https://invent.kde.org/system/kpmcore
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 23.04.3 with grep in /nix/store/ah3p2krj245vckv96hwflglvssdy7j5h-kpmcore-23.04.3
found 23.04.3 in filename of file in /nix/store/ah3p2krj245vckv96hwflglvssdy7j5h-kpmcore-23.04.3

Rebuild report (if merged into master) (click to expand)

5 total rebuild path(s)

5 package rebuild(s)

First fifty rebuilds by attrpath
calamares
calamares-nixos
libsForQt5.kpmcore
partition-manager
plasma5Packages.kpmcore

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/ah3p2krj245vckv96hwflglvssdy7j5h-kpmcore-23.04.3 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A libsForQt5.kpmcore https://github.com/r-ryantm/nixpkgs/archive/f9d355a9f0b31c0c968130c51ac272d151123e66.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/ah3p2krj245vckv96hwflglvssdy7j5h-kpmcore-23.04.3
ls -la /nix/store/ah3p2krj245vckv96hwflglvssdy7j5h-kpmcore-23.04.3/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

4 packages built:

calamares
calamares-nixos
libsForQt5.kpmcore
partition-manager

Maintainer pings
cc @peterhoeg @oxalica for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/kpmcore/versions.
meta.description for libsForQt5.kpmcore is: KDE Partition Manager core library
meta.homepage for libsForQt5.kpmcore is: https://invent.kde.org/system/kpmcore
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 23.08.1 with grep in /nix/store/xlfl898p04vqwafkjkm80n9ikschqpaa-kpmcore-23.08.1
found 23.08.1 in filename of file in /nix/store/xlfl898p04vqwafkjkm80n9ikschqpaa-kpmcore-23.08.1

Rebuild report (if merged into master) (click to expand)

5 total rebuild path(s)

5 package rebuild(s)

First fifty rebuilds by attrpath
calamares
calamares-nixos
libsForQt5.kpmcore
partition-manager
plasma5Packages.kpmcore

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/xlfl898p04vqwafkjkm80n9ikschqpaa-kpmcore-23.08.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A libsForQt5.kpmcore https://github.com/r-ryantm/nixpkgs/archive/7d99161f189769124abe9de53153e166b7aa2be3.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/7d99161f189769124abe9de53153e166b7aa2be3#libsForQt5.kpmcore

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/xlfl898p04vqwafkjkm80n9ikschqpaa-kpmcore-23.08.1
ls -la /nix/store/xlfl898p04vqwafkjkm80n9ikschqpaa-kpmcore-23.08.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

4 packages built:

calamares
calamares-nixos
libsForQt5.kpmcore
partition-manager

Maintainer pings
cc @peterhoeg @oxalica for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/kpmcore/versions.
meta.description for libsForQt5.kpmcore is: KDE Partition Manager core library
meta.homepage for libsForQt5.kpmcore is: https://invent.kde.org/system/kpmcore
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 23.08.2 with grep in /nix/store/db534dq1a5al5hv1s4vwm3aj40pd7cir-kpmcore-23.08.2
found 23.08.2 in filename of file in /nix/store/db534dq1a5al5hv1s4vwm3aj40pd7cir-kpmcore-23.08.2

Rebuild report (if merged into master) (click to expand)

5 total rebuild path(s)

5 package rebuild(s)

First fifty rebuilds by attrpath
calamares
calamares-nixos
libsForQt5.kpmcore
partition-manager
plasma5Packages.kpmcore

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/db534dq1a5al5hv1s4vwm3aj40pd7cir-kpmcore-23.08.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A libsForQt5.kpmcore https://github.com/r-ryantm/nixpkgs/archive/25e51617ff7fcf22895290bb18cc1611ae8c162a.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/25e51617ff7fcf22895290bb18cc1611ae8c162a#libsForQt5.kpmcore

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/db534dq1a5al5hv1s4vwm3aj40pd7cir-kpmcore-23.08.2
ls -la /nix/store/db534dq1a5al5hv1s4vwm3aj40pd7cir-kpmcore-23.08.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

4 packages built:

calamares
calamares-nixos
libsForQt5.kpmcore
partition-manager

Maintainer pings
cc @peterhoeg @oxalica for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/kpmcore/versions.
meta.description for libsForQt5.kpmcore is: KDE Partition Manager core library
meta.homepage for libsForQt5.kpmcore is: https://invent.kde.org/system/kpmcore
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 23.08.3 with grep in /nix/store/z70mbxzz3mqha2lynvpjz6ss7ni23j95-kpmcore-23.08.3
found 23.08.3 in filename of file in /nix/store/z70mbxzz3mqha2lynvpjz6ss7ni23j95-kpmcore-23.08.3

Rebuild report (if merged into master) (click to expand)

5 total rebuild path(s)

5 package rebuild(s)

First fifty rebuilds by attrpath
calamares
calamares-nixos
libsForQt5.kpmcore
partition-manager
plasma5Packages.kpmcore

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/z70mbxzz3mqha2lynvpjz6ss7ni23j95-kpmcore-23.08.3 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A libsForQt5.kpmcore https://github.com/r-ryantm/nixpkgs/archive/89863dcb6bbcecf8cc1e0a512e7860ec37febeb6.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/89863dcb6bbcecf8cc1e0a512e7860ec37febeb6#libsForQt5.kpmcore

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/z70mbxzz3mqha2lynvpjz6ss7ni23j95-kpmcore-23.08.3
ls -la /nix/store/z70mbxzz3mqha2lynvpjz6ss7ni23j95-kpmcore-23.08.3/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

4 packages built:

calamares
calamares-nixos
libsForQt5.kpmcore
partition-manager

Maintainer pings
cc @peterhoeg @oxalica for testing.


[BUG?] LineString difference between bounds and boundary

Expected behavior and actual behavior.
Why is the LineString boundary different from bounds?
It seems coordinates are sparsely sampled before calling boundary (with e.g. np.linspace), which might skip on minimums and maximums contained in the middle of the line.
Steps to reproduce the problem.
from shapely.geometry import LineString

x = [-106.97248045, -106.97028913, -106.96809781, -106.96590649,
       -106.97248045, -106.96371517, -106.95248231, -106.96152384,
       -106.95933252, -106.9571412 , -106.95494988, -106.95275856]
y = [39.18759405, 39.18964863, 39.19170321, 39.19375778, 39.1874456 ,
       39.19581236, 39.20610735, 39.19786694, 39.19992151, 39.20197609,
       39.20403067, 39.20608524]
line = LineString(zip(x,y))

print("xmin,ymin,xmax,ymax\n",min(line.coords.xy[0]),min(line.coords.xy[1]),
                              max(line.coords.xy[0]),max(line.coords.xy[1]))
print("bounds\n",             *line.bounds)
print("boundary\n",           line.boundary[0].x, line.boundary[0].y,
                              line.boundary[1].x, line.boundary[1].y)

The result
xmin,ymin,xmax,ymax
 -106.97248045 39.1874456 -106.95248231 39.20610735
bounds
 -106.97248045 39.1874456 -106.95248231 39.20610735
boundary
 -106.97248045 39.18759405 -106.95275856 39.20608524

Operating system
OSx 10.13.4
Shapely version and provenance
1.6.4.post1 conda-forge

@okomarov the topological boundary of a curve is its two end points, while the bounds is the limits of the minimum bounding rectangle. In general they will differ.

@sgillies Thanks for your answer, that makes sense.
I later found the boundary definition right at the beginning, under the Spatial Data Model.  I did not see it immediately because I was searching for the LineString.boundary() method, and hence was always skipping to the relevant section. It might be one of those trivial notions, but I feel that people just getting into spatial analysis would benefit from a bit of repetition.


Docs: Subject exceeds the 127 byte limit mitigation strategy

TL;DR
The troubleshooting guide suggests that you can only use shorter repo or branch names to overcome the 127-byte limit issue.
But you can also adjust the attribute mapping and shorten the subject.
Detailed design
You can overcome the 127 byte limit by shortening the google.subject in the attribute mapping.
gcloud iam workload-identity-pools providers create-oidc "my-repo" \
  --project="${PROJECT_ID}" \
  --location="global" \
  --workload-identity-pool="github" \
  --display-name="My GitHub repo Provider" \
-  --attribute-mapping="google.subject=assertion.sub,attribute.actor=assertion.actor,attribute.repository=assertion.repository,attribute.repository_owner=assertion.repository_owner" \
+  --attribute-mapping="google.subject=assertion.sub.split(':')[1],attribute.actor=assertion.actor,attribute.repository=assertion.repository,attribute.repository_owner=assertion.repository_owner" \
  --attribute-condition="assertion.repository_owner == '${GITHUB_ORG}'" \
  --issuer-uri="https://token.actions.githubusercontent.com"

Hence, in cases where the sub claim is repo:<orgName/repoName>:pull_request it will be change to <orgName/repoName>, which will shorten the google.subject to some degree.
Update documentation accordingly.
Additional information
No response

Sure, but that same value (<orgName/repoName>) is available via assertion.repository without any string manipulation. It also greatly reduces the subject granularity, which would not be advised. As such, I'm not comfortable with even documenting this option, since unfamiliar users could too-easily misconfigure access.

@sethvargo thank you for the feedback.
Would you mind explaining why a reduced subject granularity is not advised?
Context:
Due to the quirks of AWS OIDC authentication, we modified the sub to include more claims.
This broke the google auth because of the 127 byte limit.
So, do you think it's okay to shorten the google.subject if we still use other attributes in the condition?
I want to understand the implications of this and if I should reconsider my approach.

The subject (sub) is an unique identifier of the user, device, or application, idempotently consistent for the same inputs. “sub” is a standard claim representing the entity to which the token is issued. If you change the subject to be overly broad, it no longer uniquely represents the invocation, which can lead to easy misconfigurations downstream that grant overzealous permissions to a broad set of workflows and repositories.


Haiku: It's not possible to 'exit' terminal

There is no way to exit :term on Haiku. exit does not work. See screenshot.
To Reproduce
Detailed steps to reproduce the behavior:

Run `vim --clean
Type :term
Type exit

Expected behavior
Terminal should close.
Screenshots

Environment (please complete the following information):

Vim version 8.2.0628
Latest Haiku nightly
xterm-256color

haikuports/haikuports#4894

Well, either the shell doesn't actually exit and close its I/O, or there is something not implemented properly related to job and channels.

@brammool, is there a .configure flag to disable terminal? I'd like to keep it disabled on Haiku recipe until this is fixed but keep 'huge' features.

Emir Sarı wrote:

@brammool, is there a .configure flag to disable terminal? I'd like
to keep it disabled on Haiku recipe until this is fixed but keep
'huge' features.

Check src/Makefile for configure arguments.
TERMINAL - Terminal emulator support, :terminal command.  Requires the
channel feature. The default is enable for when using "huge" features.
Uncomment the first line when you want terminal emulator support for
not-huge builds.  Uncomment the second line when you don't want terminal
emulator support in the huge build.
#CONF_OPT_TERMINAL = --enable-terminal
#CONF_OPT_TERMINAL = --disable-terminal
--
Me?  A skeptic?  I trust you have proof.
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Emir Sarı wrote:
@brammool, is there a .configure flag to disable terminal? I'd like to keep it disabled on Haiku recipe until this is fixed but keep 'huge' features.
Check src/Makefile for configure arguments. # TERMINAL - Terminal emulator support, :terminal command. Requires the # channel feature. The default is enable for when using "huge" features. # Uncomment the first line when you want terminal emulator support for # not-huge builds. Uncomment the second line when you don't want terminal # emulator support in the huge build. #CONF_OPT_TERMINAL = --enable-terminal #CONF_OPT_TERMINAL = --disable-terminal
…

I tried --disable-terminal before as natural instinct, but for some reason it didn't work with Haiku recipe. And I tried just now, no avail again. I'll try again, maybe it's a recipe syntax thing...


How to generate a payload for the AES validation method ViewState?

Hello!
Test using HMACSHA256 validation method to generate ViewState and successfully execute the command.

Test AES validation method to generate ViewState, command execution failed.

The information is as follows

Looking forward to your reply

@wpf97 Please review the final version as it should have resolved the issue. I close this for now.


migration controller: improve handling of large number of migrations

What this PR does
Before this PR:
All pending migrations get re-enqueued every 5 seconds with a logged line each time.
Creating a large number of migrations completely overwhelms virt-controller.
After this PR:
All pending migrations still get re-enqueued periodically, to avoid completely changing the design of the controller.
However, the more migration objects there are, the longer they will wait before getting re-enqueued.
The logs have also been removed.
This is not perfect, but it will hopefully relieve virt-controller enough to avoid hitting timeouts on 1000 migration tests.
Why we need it and why it was done in this way
The following tradeoffs were made:
Ideally we would not keep re-enqueuing hundreds of migrations, and have a better mechanism to handle big loads.
The following alternatives were considered:
Instead of re-enqueuing migrations when the cluster/node is at capacity, have some kind of informer that re-enqueues a pending migration when another one finishes.
This would be a big departure from the current design, so a lot of work and a lot of risk like potentially "forgetting" about some migrations.
Links to places where the discussion took place:
Special notes for your reviewer
This might look like a bit of a hack, but honestly the arbitrary 5 seconds thing already is. This is just a better hack IMO.
Please don't hesitate to suggest a better way to fix this issue.
Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[ ] Design: A design document was considered and is present (link) or not required
[ ] PR: The PR description is expressive enough and will help future contributors
[ ] Code: Write code that humans can understand and Keep it simple
[ ] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[ ] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[ ] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[ ] Community: Announcement to kubevirt-dev was considered

Release note

Large number of migrations started at the same time should be less of a problem now.

Hey @jean-edouard! I was thinking about alternative solutions and it occurred to me that instead of randomization, we could re-enqueue items based on the position in the list of incomplete migrations relative to saturation. Let me explain it taking only ParallelMigrationsPerCluster as an example.
Suppose that the list of unfinishedMigrations has 10 elements and the ParallelMigrationsPerCluster is 5 and there are currently 5 running migrations (the list of concurrent migrations is saturated). The idea is that the element at position 5 will be re-enqueued after 5 seconds, the one at position 6 by 10, and so on...
This can easily be achieved by looking at the list index and calculating the waiting time as:
(<element-index> - `ParallelMigrationsPerCluster` + 1) * 5

The argument would be quite similar when it comes to ``ParallelOutboundMigrationsPerNode`, clearly having the list of unfinished migrations from that node.
This would create a distribution based on the "distance" of the element from the saturated queue.
At the performance level, we could improve things by using a map instead of a slice.
What are your thoughts on this?
Please let me know if something is unclear. Thank you!

/close
https://github.com/kubevirt/kubevirt/pull/11616 makes more sense to me


Sync seems to be broken in mobile version of Obsidian

Love that you made this and it works great on desktop/computers. However on iOS version of Obsidian, it creates the folder but doesn't put anything in it so it's empty. Let me know how I can help debug this.
Thank you!
Ray

Can confirm it. On the mobile Version happens nothing.

Unfortunatley I dont have an iPhone, but seems to work on iPad Obsidian version 1.2.3(57)

I can confirm that it doesn't work on mobile. Latest version of the Android app running on the latest Android OS on Pixel 6. Is there a logging option to generate sync errors?


app_update.bin is not getting generated by west build

I recently bought a NRF9160 feather. I'm currently stuck here at loading the file into the bootloader.
When I run west build -b circuitdojo_feather_nrf9160_ns via the Zephyr Tools build-command a app_update.bin is not getting generated for some reason. I tried building this this  very basic blinky code.
But west flash -r nrfjprog --erase --softreset isn't getting executed since it is looking for that file first. Then this warning of the extension triggers.
This is the output of west build from the zephyr tools:
Executing task: west build -b circuitdojo_feather_nrf9160_ns

[0/16] Performing build step for 'tfm'
[42/47] Linking C executable bin\tfm_s.axf
Memory region         Used Size  Region Size  %age Used
           FLASH:      129376 B       254 KB     49.74%
             RAM:       50296 B        88 KB     55.81%
[47/47] Generating tfm_s_signed.bin
image.py: sign the payload
[2/2] cmd.exe /C "cd /D C:\Users\max\Desktop\zephyrproject\zephyr\samples\blin...max/Desktop/zephyrproject/zephyr/samples/blinky_nrfed/build/zephyr/zephyr.elf"

Is there anything suspicious? What could be the reason that this file isn't there???

Looks like you're not using the NFED samples but the Zephyr ones. You're missing: CONFIG_BOOTLOADER_MCUBOOT=y. Looks like you have an unconventional setup. I recommend the Getting Started for setting up your project.
Feel free to post any other questions through your journey on the community forum. I don't monitor Github very often.


Correction for raw affiliation Centre for Functional and Metabolic Mapping (CFMM), Robarts Research Institute, Western University, London, Ontario, Canada

Correction needed for raw affiliation Centre for Functional and Metabolic Mapping (CFMM), Robarts Research Institute, Western University, London, Ontario, Canada
raw_affiliation_name: Centre for Functional and Metabolic Mapping (CFMM), Robarts Research Institute, Western University, London, Ontario, Canada
new_rors: 02grkyz14
previous_rors: 01e36dv41;02grkyz14
works_examples: W4363645571;W4323076722
contact: 49f7103569db94e64435663224a88dcc:b7def2058026c4d4 @ uwo.ca

This issue was accepted and ingested by the OpenAlex team on 2024-12-19. The new affiliations should be visible within the next 7 days.


Scope Auth Plugin introduces Refs undefined error

Hello,
Attempting to use the scope auth plugin but when it's included I get the following error:
Error: Ref undefined has not been implemented
    at ConfigStore.getTypeConfig (c:\...\node_modules\@pothos\core\src\config-store.ts:227:6)
    at BuildCache.getTypeConfig (c:\...\node_modules\@pothos\core\src\build-cache.ts:122:41)
    at map (c:\...\node_modules\@pothos\plugin-scope-auth\src\index.ts:144:29)
    at Array.map (<anonymous>)
    at PothosScopeAuthPlugin.createStepsForType (c:\...\node_modules\@pothos\plugin-scope-auth\src\index.ts:143:33)
    at PothosScopeAuthPlugin.createResolveSteps (c:\...\node_modules\@pothos\plugin-scope-auth\src\index.ts:200:14)
    at PothosScopeAuthPlugin.wrapResolve (c:\...\node_modules\@pothos\plugin-scope-auth\src\index.ts:67:24)
    at reduceRight (c:\...\node_modules\@pothos\core\src\plugins\merge-plugins.ts:71:39)
    at Array.reduceRight (<anonymous>)
    at MergedPlugins.wrapResolve (c:\...\node_modules\@pothos\core\src\plugins\merge-plugins.ts:70:25)

I've followed the troubleshooting guide and this error doesn't occur without the plugin. The pothos folder structure in my project is below. The index files in each folder such as objects exports each file like this:
export * from './Dog'
export * from './Cat'
export * from './external' // this folder has another index that exports PetOwner

│   builder.ts
│   index.ts // export * from './schema'
│   schematypes.ts
│   schema.ts // imports index
│
├───enums
│       PetType.ts
│       index.ts
│
├───inputs
│       NumberFilterInput.ts
│       index.ts
│
├───interfaces
│       Animal.ts
│       index.ts
│
├───mutations
│       createDog.ts
│       createCat.ts
│       index.ts
│
├───objects
│   │   Dog.ts
│   │   Cat.ts
│   │   index.ts
│   │
│   └───external // External entities via federation
│           index.ts
│           PetOwner.ts
│
├───queries
│       getDogs.ts
│       getCats.ts
│       index.ts
│
├───scalars
│       Date.ts
│       DateTime.ts
│       index.ts
│
├───unions
│       index.ts
│       LoginResult.ts
│
└───_helpers
        extendIdField.ts // helper to extend entities
        index.ts
        ShapeFromInputRef.ts // Gets TS type from InputRef

The schema.ts file looks like this:
import { builder } from './builder'
import './enums'
import './inputs'
import './interfaces'
import './mutations'
import './objects'
import './queries'
import './scalars'
import './unions'

export const schema = builder.toSubGraphSchema({})

The index at the root looks like this:
export * from './inputs' // to use inferred types from refs
export * from './schematypes'
export * from './schema'

It works when I only import "standalone" portions of the schema like scalars, inputs, and enums. After some playing around with the imports it seems to be interfaces that cause the issue but I can't be sure.

Very weird that the plugin changes the behavior.  I do see a potential circular import issue I should fix in pothos. I think what I will do is add a check when defining interfaces that the refs are all defined.  This will let people more easily find when there is an issue, and I should be able to log a message saying exactly how it can be fixed.  The other part of the fix would be to allow interfaces to be defined as interfaces: () => [Interface1, interface2] instead, and avoid trying to access the interfaces until the schema is built.  This would likely fix your issue (I am still not sure exactly the issue you are running into is because it should be consistent with and without the plugin).
I'll probably try to add this some time this weekend.
In the mean time, I can try to help you troubleshoot.  What I would recommend is logging out any interface refs you are using in your schema right before passing them to an object/interface.
eg:
import { Animal } from '../Interfaces';

console.log(Animal);
builder.objectType('Dog', { interfaces: [Animal] ...});

This will hep you track down which interface ref is actually undefined.
Once you know which interface is causing the issue you can try to figure out the circular import pattern that is causing the issue.
One general tip that might help: Try importing directly from the file that defines a type rather than from index files.  This can be slightly more verbose, but importing from index can cause a lot of issues.  In my own projects I have started to avoid using them whenever possible.
Let me know how this goes, and if you make any progress.  Happy to help debug further if the above doesn't get things working.

I would probably rewrite my index files to just import rather the to re-export.
// objects/index.ts
import './Dog'
import './Cat'
import './external'

I am referencing all my refs via SchemaTypes where possible. So interfaces are just string arrays. I will try the import approach for objects and interfaces.

Oh interesting... That is very odd.  I'll have think through how a string could become undefined.  If you are passing in strings everywhere, then I really don't know what's going on.  Not sure if your code is sharable, but if it is I'd be happy to take a look and try to debug it that way

I think I figured it out.  It's not an import issue, there is a bug in the scope auth plugin

Unfortunately, my code isn't shareable. Happy to discuss further to debug or help create a similar environment.

I think I figured it out. It's not an import issue, there is a bug in the scope auth plugin

This makes sense as there isn't an issue without the plugin. I did try replacing export * from with import and that didn't resolve it. What was the bug?

This actual issue is pretty complicated, but the simple version is line should pass the interface ref instead of the name here: https://github.com/hayes/pothos/blob/e2ad8c8a7486d8d209f6cd44a01d283104945659/packages/plugin-scope-auth/src/index.ts#L144
The underlying issues is obfuscated by generic types behaving weird in plugin internals since it doesn't know what type names you passed the the builder constructor.

Merged a fix for this issue, should be published in a few minutes, let me know if you have any more issues after upgrading.
Also added some of the ref verification logic, and the ability to lazy load interfaces by wrapping them in a function as described above (this probably isn't relevant to your use case).

So far, so good! Don't see the issue anymore.
Thank you for getting this out so quick. I've really enjoyed using pothos.


Message didn’t show up in #social as unread in LHN, but I got the email notification. ie. LHN is not updating from posts in #social til it's clicked on

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number:
Reproducible in staging?: needs reproduction
Reproducible in production?: needs reproduction
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @JmillsExpensify
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1704231385914329
Action Performed: (Updated by @mallenexpensify on Jan 17)
Precondition: must have access to #social channel in NewDot on the Expensify Chat workspace (hence why this needs to be internal, Matt A hasn't been able to reproduce in other rooms)

Have focus on a report that isn't #social
Have others post to #social or just wait 15 mins for chats to come in, which is usually pretty frequently

Expected Result:
New chats to show in LHN for the #social room
Actual Result:
New chat don't show in LHN until the chat is clicked on, then chats load in the main #social report and LHN updates.
Workaround:
unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01059dcd731dd4aa05
Upwork Job ID:<PHONE_NUMBER>220931584
Last Price Increase: 2024-01-17

@MitchExpensify if this never happens to you, will you unassign and put me on as BZ?  Thx

Still unable to reproduce reliably https://expensify.slack.com/archives/C049HHMV9SM/p1705174729264039?thread_ts=1704231385.914329&cid=C049HHMV9SM

Switching to Weekly while we figure out how to reproduce

If I had to guess, the repro step involves putting your computer to sleep or closing the lid.
I can most-reliably reproduce it with the #social room.

Tried closing the lid and sleeping in a variety of ways to no success..
I think I can only close this issue at this point and we can reopen if we are able to reliable reproduce

Gonna take over

It's not just #social, just happened with chat with Scott too, got a desktop notification 20 mins ago, noticed it didn't show in LHN, loaded once I clicked it

Also being discussed here

Tested in/on a test room and wasn't able to repro.  Wonder if it's because #social has a lot of chats? files?

Just adding in here that I experience it too - persistently always with #social, but inconsistently with other chats as well. It was worst when we were having issues during harvesting (#fireroom-2024-01-10-site-slowness). And it's definitely worse for chats that have a lot of content.
https://github.com/Expensify/App/assets/59587260/d0826320-a5bb-4208-a98c-f88084669ad7

Shit, made this External then realized that External folks don't have access to our social channel, changing.

Updated the OP with repro steps, added to the #vip-vsb project and posted in that room.  It's internal cuz contributors don't have access to #social (and I'm unable to reproduce in other rooms, some which I have many dozens of chats in)
https://expensify.slack.com/archives/C066HJM2CAZ/p1705534245864589

Also checking with QA to see if they have any high traffic rooms that contributors can be added to

^^ ooooh, Marc might have a fix above
gonna put this on hold now, pending that PR 🤞

Maybe not directly related but, when I just clicked into #social, it took almost 30 seconds for the chats to load (and the most recent chat to show in LHN)

From Marc here
In general, I would say for any situations like this i.e. where there are chats missing from the LHN the process to help someone debug it would be:

Identify the reportID of the chat that you expect to see (ask the other person if you need to)
Confirm that the reportID is not in your Onyx data report_[reportID] key
If it is, check to see what the report.notificationPreference value is
If it’s not, look at the Network tab and try to see if it came back in the usual places where we might expect to see it i.e. GetMissingOnyxUpdates  or ReconnectApp
Previous step requires you have the Network tab open and capturing the responses before you open the app

https://github.com/Expensify/Web-Expensify/pull/40585#issuecomment-1905064112
Above is on staging, going to try to do some testing later. Also wanting to suss out more examples of where this occurring because, for me, it's almost exclusively in #social.

PR above hit staging two days ago and I'm still experiencing the bug on Version 1.4.31-4
Repro steps are still the same.
@marcaaron any idea what next best steps might be?  I can post in #engineering to try to get more 👀 on it

There are a lot of potential things to look into. Generally speaking, it is very hard (maybe impossible?) to confirm the delivery of an update from the server to the client in realtime (or after the fact). If you didn't see the LHN update but got an email then the basic problem would logically be one of these:

A. Got the update, but something prevented the LHN from updating (possible but unlikely)
B. Never got the update

B has another layer of complexity because we have "reliable updates" now which means that if you miss an update we should be sending you those updates at some point. I think we don't really do that until you reconnect from being offline or take some other kind of action in the app.

This could also explain it https://expensify.slack.com/archives/C0671JDRKQW/p1706062397300099?thread_ts=1706048639.315449&cid=C0671JDRKQW

Thanks for the deets and especially the link. I commented there, asking for an update once I can test via staging.
Also also ran into another issue of #social  not updating

Send message in iOS
Stay on the screen with the keyboard and compose box showing
Ask someone else to confirm once a new post is added after yours
Observe your message is the last shown on iPhone.

Random note... I noticed when I started up this morn and went to #social, the chat in LHN, the one that initially showed when I went to #social then the one that loaded were all different.

Def doesn't seem to be getting better, I've updated NewDot 4 times today and am continually testing, both Flo and Scott have run into issues today too. https://expensify.slack.com/archives/C049HHMV9SM/p1706569754923139?thread_ts=1706551202.735269&cid=C049HHMV9SM
Checking in #ngineering https://expensify.slack.com/archives/C03SSAQ7P/p1706569735098989

Maybe this is related to what is being fixed here: https://github.com/Expensify/Web-Expensify/pull/40434
AddComment can crash if the chants has many participants. Maybe sometimes it crashes before sending out the onyx updates?

Another (potentially) interesting bit.  I closed/quit NewDot last night.  When I opened it this morn, it showed an old chat in LHN or #social.  So, even with a clean/fresh instance, it's still not loading and showing correctly.
Thanks for the comment @aldo-expensify , I'm going to follow that PR.

Thanks for the comment @aldo-expensify , I'm going to follow that PR.

From my testing yesterday, even if AddComment doesn't crash anymore, the push events still don't arrive for big chats, so that PR may not be the final solution

the push events still don't arrive for big chats,

Is this specific to Pusher?
Also, possibly off topic a bit, if the push event doesn't happen for a big chat, does that affect it showing in LHN and also in the main chat?  (there's a bug where a bunch of chats from a couple weeks ago don't show in #social, they disappeared)

does that affect it showing in LHN and also in the main chat?

I think the bug makes you miss the message itself and the latest visible message in the LHN (both updates come from the pusher when someone sends a message).

bunch of chats

Are you referring to "messages"? are you saying that they sent a message in social that failed to be posted?

This is  the other bug (that I don't think is directly related but ¯_(ツ)_/¯  )

https://github.com/Expensify/App/issues/34687

I can confirm that messages in #social are throwing errors:

Log of the command running out of memory: https://www.expensify.com/_devportal/tools/logSearch/#query=request_id:("84dc4505deef2dab-YVR")+AND+timestamp:[2024-01-30T18:54:56.360Z+TO+2024-01-30T20:54:56.360Z]&index=logs_expensify-026534
This does allow the message to be posted (saved in the database), but the pusher events are not sent so no one gets notified/updated with the new message

This is the other bug (that I don't think is directly related but ¯_(ツ)_/¯ )

[$500] #Room - When scrolling up in #social Room a weird mix of old chats show up from different dates #34687

that looks different, but can't be certain until investigated :P

I can confirm that messages in #social are throwing errors:

ooooh, and the PR is fixing the AddComment bug, right ? so there's a good chance that PR will help or fix things, right?!?!

ooooh, and the PR is fixing the AddComment bug, right ? so there's a good chance that PR will help or fix things, right?!?!

Apparently it is not fixing it completely. In my local testing of the PR, the command doesn't crash anymore, but I still don't get the pusher events. I haven't investigated why the pusher events are still getting lost.

ooooh, i got a notification and #social updated in LHN. I unsure if it's consistent though so will keep checking/testing

Shared in #expensify-bugs
https://expensify.slack.com/archives/C049HHMV9SM/p1706818982723529?thread_ts=1704231385.914329&cid=C049HHMV9SM

Tracked another ~dozen updates in #social and it appears that I'm receiving the desktop notification for all chats and that LHN is updating for each comment.

Closing, issue has been fixed,


Typescript - upload() method not supported

Hi, i want to say that i appreciate the work you are doing!
I am using nuxt with typescript and followed your setup. It seems that the cloudinary upload() method is not supported for typescript (can be fixed by adding "/ @ts-ignore"):

But the other api method such as image() works.
I was wondering if it is going to be added in the future or it is a bug?
Best regards,
Johnny

@JohnnyChenJiaHao oops thank you for reporting this :). It's a small bug in type declaration when I did the refactoring and migration to TypeScript. I will have it fixed in the next release!
Have a nice day!

@JohnnyChenJiaHao oops thank you for reporting this :). It's a small bug in type declaration when I did the refactoring and migration to TypeScript. I will have it fixed in the next release!
Have a nice day!

@JohnnyChenJiaHao it's fixed in 1.0.3-beta-3. Let me know if there is any issue :)

@JohnnyChenJiaHao it's fixed in 1.0.3-beta-3. Let me know if there is any issue :)