feat(RELEASE-1176): only sign registry.access if required

rh-sign-image and rh-sign-image-cosign will now only sign registry.access.redhat.com references if requires_terms is false in the corresponding repository object in Pyxis.
If require_terms is true (the vast majority of repos), signing of registry.access references will be skipped which will result in 50 % reduction of signing
requests.
Several changes are included:

publish-pyxis-repository provides a new result that points to a file that contains a list of repos where signing of registry.access references is needed.
rh-sign-image and rh-sign-image-cosign take this result as a new mandatory parameter and will skip registry.access signing unless the given repo is included in the file.
rh-advisories and rh-push-to-registry-redhat-io pipelines were modified for this. The order of tasks was also slightly modified so that publish-pyxis-repository runs earlier in the pipeline.

/retest

/retest

/retest

/retest

/retest

/retest


Force scroll to top on page change

Makes page changes behave like a normal site.

Coverage decreased (-0.08%) to 81.294% when pulling fdec3877a18acfd6f3e459dc6750c7cd0e96ba17 on eatonphil:push-and-jump-to-top into 61d27f77bb03a9dd35c13d408879e7e002f51376 on linode:master.


[Guide] Error message typo: "Miriam" in explanation, "Victor" in codes

Description
Typo:
The name "Miriam" is used in the explanation, but the error and solution codes (before and after) uses the name "Victor".
Location
Understanding mistakes
https://github.com/google/codeworld/blob/277d0517b25dce60e748ded5782b9cd9bc8d05a8/web/help/GuideUnit1.md#understanding-mistakes
The third error:
Multiple declarations of nametag
Below the error code:
program = drawingOf(nametag)

nametag = lettering("Victor")
nametag = circle(10)

The first sentence in the explanation:

One line says nametag means the text "Miriam", but the second line
says that nametag instead means a circle with a radius of 10.

Issue
The explanation states that:

nametag means the text "Miriam"`

but both the error and solution codes (above and below the explanation) uses the name "Victor".
A Possible Solution
The first sentence of the explanation with the name changed to match the code, looks like this:
One line says `nametag` means the text "Victor", but the second line
says that `nametag` instead means a circle with a radius of 10.

Additional Notes
The name "Miriam" is used in the error and solution codes for the next error
(Couldn't match type Program with Picture), that's probably where the name came from.
Possibly if both error sections where written/edited at the same time.

Fixed.  Thanks!


How will Swagger handle schemas with same name?

I like this architecture of a project, but I see one problem here when wanting to use Swagger as API documentation.
I'm not sure how Swagger will support the schemas with same name.

The solution is described here:
https://stackoverflow.com/questions/46071513/swagger-error-conflicting-schemaids-duplicate-schemaids-detected-for-types-a-a


SubdomainNavBar not forwarding className correctly

SubdomainNavBar isn't forwarding the css class attribute value correctly, as it's overriding the internal classes due to spreading of props.
Relevant line: https://github.com/primer/brand/blob/fa0a2bf40345802ad7d4cd4dfb9860edf09eba19/packages/react/src/SubdomainNavBar/SubdomainNavBar.tsx#L97
Should be fixed by destructuring the className from rest and composing into the existing className value.

Fixed and in production: https://github.com/primer/brand/blob/e8418073913cb9b8b514b665178f3e122f3fd85f/packages/react/src/SubdomainNavBar/SubdomainNavBar.tsx#L98


removed call to csharp_bind_target if csharp is not enabled.

Sorry for ignoring this for so long. Looks like im not getting email notifications about PRs. Could you please not loose new line at the end of file? :+1:


merge from template-kronos-app

package.json

chore(deps): add ^10.13.2 remove ^10.13.1 (devDependencies.npm-pkgbuild)

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

npm package (@latest dist-tag)
v1.10.153
GitHub release

Your semantic-release bot :package::rocket:


[1.9] Breaking Advanced Powercell immediately loses 1m RF

So I have 2 Powercells + 1 advanced powercell = 3m RF
http://i.imgur.com/B0uxml2.png
If I break the Adv powercell the remaining 2 basic ones retain the 1m RF (500k each)
http://i.imgur.com/OAN39Y3.png
However the 2m RF which is supposed to be kept in the Adv Powercell is only 1m RF
http://i.imgur.com/Fc7nwrW.png
So when I replace the adv powercell down again my 3m RF is now 2M RF and starts charging up again
http://i.imgur.com/A90sN2p.png
rftools-1.9.0-4.47.jar
mcjtylib-1.9.0-1.8.3.jar
Forge 1887

Fixed next release


ARROW-10985: [Rust] Update unsafe guidelines for adding JIRA references

See changes for details

Codecov Report

Merging #8969 (8ac55cc) into master (091df20) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #8969   +/-   ##
=======================================
  Coverage   83.22%   83.22%
=======================================
  Files         196      196
  Lines       48232    48232
=======================================
  Hits        40142    40142
  Misses       8090     8090

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 091df20...8ac55cc. Read the comment docs.


Publish debug symbols to source link

Is your feature request related to a problem? Please describe.
Visual Studio has a feature called Source Link which allows for stepping into the external code if it is in a NuGet package with debugging symbols with link to a GitHub repository. This will allow a better debugging experience without the need to clone Stride and fully compile a dev build of the packages.
Describe the solution you'd like
Include snupkg generation and publishing for official releases. See https://github.com/dotnet/sourcelink.

I have added this to toolkit. If it is going to work we can use it also in Stride NuGet packages. I will update this issue once all tests are done.


Main contents of "Traffic Monitor" and "Dispatcher Planner"

I have attended a Romi-H webinar and found a slide to describe the Romi-H structure. The slide is shown as below:

May I know what are the main contents of the module "Traffic Monitor" and "Dispatcher Planner" in the "The Core Systems"?

This diagram is a rough abstraction of the concepts behind RoMi-H, and these bubbles won't always map to a single specific module that can be pointed at. As we iterate on the design and implementation of RoMi-H, I think we'll start to converge on a high-level diagram that maps more accurately to specific modules, but for now these diagrams need to be viewed in the abstract instead of in the literal.
The "Traffic Monitor" could refer to the component of the schedule database that announces traffic conflicts whenever they appear. That functionality currently lives inside the schedule node.
The "Dispatch Planner" module is currently a work in progress. So far the demo platforms that have been developed for RMF did not require a planner to dispatch tasks to different fleets, because in all the demo platforms done so far, each task type could only be performed by one of the fleets. So task dispatching was trivial: The task gets assigned to whatever fleet is capable of performing the task, while the rest of the fleets just ignore the task request.
We are currently working on a true dispatch planner and formal task bidding system which we're aiming to include in release 1.2.0, slated for end of December 2020. The idea is that every fleet that can perform a task request will offer a bid for how much it would "cost" them to perform a task, and the bid with the lowest "cost" will be the winner. The "cost" will be determined by two factors:

How quickly the task is finished
How much other tasks get delayed if the new task needs to preempt them

Hi @mxgrey
Thank you for your detailed explanation!
I have 2 more questions to ask:

What's the main difference between "rmf_traffic" and "rmf_traffic_ros2"?
Where is the Costmap located in the Romi-H system?

What's the main difference between "rmf_traffic" and "rmf_traffic_ros2"?

rmf_traffic provides a middleware-neutral implementation of the core traffic scheduling algorithms and utilities.
rmf_traffic_ros2 provides convenient wrappers for using the rmf_traffic utilities as part of a distributed ROS2 system.
There is no ROS2 dependency in rmf_traffic, so those utilities can be used in any kind of application or distributed across any kind of middleware.

Where is the Costmap located in the Romi-H system?

There is no costmap representation in rmf_core. Costmaps are one method that is typically used for representing volume occupancy for autonomous navigation planning. While it's true that the traffic utilities deal with navigation planning, they are principally concerned about identifying conflicts between the intended routes of autonomous vehicles. The traffic utilities are not responsible for the "local" navigation of vehicles around static obstacles in their environment.
Different robot platforms often have different representations of costmaps, many of which may be proprietary. On top of that, different robot platforms with the same costmap representations may still require different costmap values because of differences in the robot's external profile. Because of these factors, we leave it to the robot platforms themselves to determine how they represent their costmaps.
If it's important for a system integrator to take a robot's costmap into account when performing traffic planning, they can implement a custom rmf_traffic::agv::RouteValidator that uses the robot's custom costmap when determining whether a candidate route is valid.

Hi mxgrey,
I have found two planning files in rmf_core,
1: ../rmf_fleet_adapter/src/rmf_fleet_adapter/jobs/Planning.cpp
2: ../rmf_traffic/src/rmf_traffic/agv/Planner.cpp
Are they doing the different tasks?
Thank you!

rmf_traffic/src/rmf_traffic/agv/Planner.cpp implements the API provided by the rmf_traffic/agv/Planner.hpp header, which provides the rmf_traffic::agv::Planner class, its nested classes (namely Planner::Configuration, Planner::Options, Planner::Start, Planner::Goal, and Planner::Result), and the rmf_traffic::agv::Plan class (along with its nested class Plan::Waypoint). This API is designed to be as generic and generally usable as possible.
rmf_fleet_adapter/src/rmf_fleet_adapter/jobs/Planning.cpp uses the rmf_traffic/agv/Planner.hpp API alongside rxcpp and ROS2 to implement a multi-threaded reactive traffic planner for fleet adapters. It's used for both "full control" and "traffic light" categories of fleet adapters.

Hi mxgrey,
For the "conflict detection" algorithm, I still cannot understand what are the rules or conditions for rmf_traffic to determine the conflict status. Would you please give me some explanations about that? Thanks a lot!

For the traffic management framework, there are three important pieces of data that every participant (i.e. robot) must provide:

itinerary: a sequence of piece-wise cubic splines that describe where the robot intends to be in the future
footprint: a shape that describes the approximate 2D outline of the robot
vicinity: an area around the robot which needs to be kept clear of other robots to avoid interfering with the robot's operation

The footprint and vicinity of a robot follow along the itinerary as a function of time. Given Robot A and Robot B, a conflict happens if the position of Robot A ever gets closer to the position of Robot B when the footprint of Robot A is inside the vicinity of Robot B.
This means that robots are allowed to get closer to each other as long as the footprint of one isn't touching the vicinity of another.
This also means that it's never a conflict for two robots to move further away from each other. This point is important for dealing with situations where robots start out inside of each other's vicinity, which can happen due to inaccurate predictions or network latency. When that happens, we simply require that the robots make a plan to immediately move away from each other.

Hi mxgrey,
May I know where is the main() function to call the conflict detection procedure? Thanks!

Traffic conflict detection is implemented in the rmf_traffic library, and that library gets used in many many places within the RMF system, including in all of the traffic planners and traffic negotiators.
But I'll guess that you're asking for the entry point of the ROS2 node that takes care of announcing conflicts that show up on the schedule. The main() function for that node can be found here. That function spawns and runs an rmf_traffic_ros2::schedule::Node instance. Inside of that instance, there is a thread running that is dedicated to detecting and reporting any conflicts that show up on the schedule.

hi mxgrey,
I have seen doxygen  folder in the rmf_core repo(rmf_fleet_adapter/rmf_rxcpp/RxCpp-4.1.0/Rx/v2/examples/doxygen/).
Can we generate some class diagram or pseudocode for rmf_core (especially DecteConflict and Negotiation) from files in this folder? Thanks!

The file you're referring to comes from the rxcpp library which is being used internally by the rmf_fleet_adapter package. It's a third-party library which we've integrated into rmf_fleet_adapter by simply copy/pasting the source code into our repo.
I don't know for sure, but it looks to me like the doxygen folder you've pointed to is meant to provide code snippets that are probably used by rxcpp's doxygen examples. It doesn't help with the process of actually generating any documentation.
That being said, all the public API headers of all the packages in rmf_core have been thoroughly documented with doxygen-friendly markup. It should be straightforward to set up scripts to generate doxygen documentation for the rmf_core packages if anyone is interested in contributing that.

Closing as this is not an issue. To continue discussing this topic, please open a discussion.


fixed variable perf bug and added debug arg for testing on each epoch

Because of random word embedding for out of vocabulary words, the performance of the final saved model was variable. This is now fixed.

Remove main.py line 148-151 for calculating MAP and MRR for each epoch.
--> These statements are only executed when main.py is run with the argument --test_on_each_epoch. This was put in place because @HTAustin wanted to see the results over test_set after each training epoch.
--test_on_each_epoch is part of the "debug group" of arguments (main.py: lines 96-101), all of which can be removed when the model is deemed satisfactory to our requirements.

line 49 in train.py init oov_term with random vector inside load_input_data() . So everytime we call load_input_data(), there will be a new random oov_term vector. Should init oov_term verctor be in main.py. So oov_term is consistent and unified.
--> load_input_data needs to be called only once by each instance of Trainer immediately after instantiation. The random seeds are reset in Trainer::init(). Thus oov_term vector is created the same for each trainer instance. I guess the best place for oov_term vector is in Trainer::init.

Better to change oov_term to unk_term.
--> Sure.


Allow pseudo columns in templating environments

Along with introducing pseudo columns in the visible column list, it would be very helpful to have some new annotation mechanism where a pseudo column definition could be injected into the mustache (or handlebars) template environment (without adding it to the rendered visible columns).
We should think this over a bit before diving in.  One question is whether such a mechanism should be additive to the current environment or instead override the default.  An override behavior could be better for future performance, so we don't have to prepare all kinds of raw and rendered data "just in case" the DBA wants to reference it in a template. Instead, they would have a way to declare their data dependencies and we only need to prepare content actually needed by their templates.
The pseudo column mechanism is also more general than the previous foreign key based content, so that feature would seem largely redundant once this is available...
@hongsudt @robes @ljpearlman @bugacov  @mikedarcy

@ljpearlman I would like your opinions on this as well..

I'm not sure I understand the two alternatives here, but I am very, very, very strongly in favor of having the DBA specify what data they need in advance instead of having everything fetched just in case. In general I find myself wanting to go less "wide" (not bring in every linked table) and more "deep" (traverse two layers of foreign key) than the current implementation allows.

I'm not sure this is the right place to put all this, but here are some related use cases. I think the first two are covered by both alternatives listed above, but I'm not sure about the third.

We have many foreign keys that don't get used at all in recordset displays; pre-fetching all of them slows performance a lot (this is related to ermrest:193).

We have many cases where we want to link to related records for tables that are related by a relatively long series of inbound and outbound foreign keys. For example, in GUDMAP, the Specimen table has an inbound fk from an association table called Specimen_Probe, which has an outbound fk to the Probe table, which has an outbound fk to the Gene table. We want to see related genes on the Specimen table, so we currently have a table called Specimen_Gene_Association that we maintain with a series of triggers, and we show this as an inline table on the Specimen page.

We have some cases where we would like to do the equivalent of removing the one-hop limitation from row_markdown_pattern. For example, we have a table called Specimen that has outbound foreign keys to other vocabulary-type tables (species, developmental stage, etc.). We'd like the row display for the Specimen table to reference columns (i.e., the name for each of these things) from those vocab-like tables. Technically, we can do this, and it will show up in the title of each Specimen record page, but we'd also like Specimen links to show up that way in tables that reference the Specimen table.
Currently, we're cheating a bit by using names as our foreign keys in vocabulary-like tables, but as we move to the more standardized vocabulary format, this will become more of an issue, as we'll need to link to dbxrefs instead of names (names in the new model are not, by themselves, unique; what's unique is the combination of name, controlled vocabulary, and "obsolete" status; we'll probably end up with only one non-obsolete term for each name in each domain table, but we may have obsolete and non-obsolete terms with the same name).

If you could show how these two cases could be expressed in each of the alternatives you listed above, that would help me understand the differences:

Given the tables:
Specimen <- Specimen_Probe -> Probe -> Gene (resulting in a many-to-many Specimen<->Gene mapping), how would we show Genes in the Specimen table display?

Given the tables:
(Many tables) -> Specimen -> Developmental_Stage, how would we annotate the Specimen table so that the Developmental Stage.Name column shows up as part of the display for the Specimen link in the tables that link to it?

@ljpearlman I actually think both of your scenarios above are mostly orthogonal to this topic and will need other enhancements to make them practical.
The new pseudo column aggregates feature allows you to include an array of scalars from the Gene table per Specimen in the recordset results. Shortly, I expect it will also support an array of Gene row-names, i.e. supporting entity: true pseudo column array aggregates. However, it currently renders the array as a comma-separated list of members and does not allow you to customize it with a markdown pattern on that pseudo column.  It seems to me we should be able to add a way for the DBA to supply such a markdown pattern as some new fields in the pseudo column definition and/or some new context key for the existing table and column display annotation.
Unfortunately, we don't have composition to allow a row-name presentation on Specimen to use external values and somehow turn that into a different pseudo column for each of your many referencing tables. In practice, I think you'll still have to denormalize development stages into your specimens if you want to render them that way.  FWIW, there is a hack you can do with an overlapping composite foreign key from Specimen to Development_Stage to denormalize this content w/o any triggers.

This was a long time ago, but I think the reasoning in the second sketch was to stick with the mustache-friendly environment hack, so each source gets stored into two separate environment fields key and _key just like the columns are currently mapped.
The other sketch assumes we will discard that old convention and use sub-fields to access raw vs display values.  I think we could also define a hybrid of the first sketch to allow some of the brevity, by allowing different syntactic short cuts?
{
  "source1": {"source": ...},
  "Column1": true,
  "Column2": "Column 2",
  "fkey1": ["Schema", "Constraint1"],
  ...
}

The {"source"...} syntax is of course the fully general scenario with arbitrarily assigned environment key.
The true (or 1?) syntax avoids repeating a column name if it can be used exactly as environment key.
The "Column 2" syntax allows arbitrary column names where the DBA must provide a mangled environment key since we won't automatically assign environment keys anymore nor do name mangling.
The ["Schema", "Constraint1"] syntax allows the simple foreign key shorthand but with DBA assigned environment key.

If we are going to go forward with handlbars and hopefully deprecate mustache, I lean towards also moving towards this sort of explicit control and deprecating our old environment construction rather than keeping it around as some perpetual backwards-compatibility mode...

In principle, that sounds good to me. But what is the impact on deployments. If backward compat is dropped, will the effort (to update existing annotations) be so great that we will have some deployments lag behind. Etc. Perhaps one way to avoid that situation is to provide an upgrade script written in deriva-py that walks the model and updates all older annotations to the new format.

tag:isrd.isi.edu,2018:env-variables:
{
   "columns": [col1, col2],
   "fkeys": [  [ schema, constraint ], ... ],
   "sources": [
      {"source": [ sourcepath1 ], "entity": boolean, "key": "key1"},
      ...
   ]
}

"tag:isrd.isi.edu,2016:visible-columns": {
  "detailed": [
      {
        "source": ["key1","key2"],
        "display": {
          "markdown_pattern": "<prefix> {{{$pcol.key2}}} <suffix>",
          "template_engine": "handlebars",
          "page_size": "",
           "row_order": ""
           "aggregate-column": true
        }
      }
   ]
}

@hongsudt @karlcz
When we designed this we were mainly focused on the source syntax. Which means that we are now going to be able to access pseudo-column in templates that are directly defined in the source syntax (in visible-columns and visible-foreign-keys annotations).
Since some of the pseudo-column data might not be available on load, we needed a way to signal chaise/ermrestjs when we have the data and therefore should process the given template. For that, we've added waitfor which is a flat list of dependencies.
Now we need to evaluate this design. To see if it make sense to be able to access pseudo-columns in templates that are defined for other annotations (which ultimately means whether it makes sense to add waitfor to these annotations or not).The following are the different annotations that are utilizing templating.
1. Citation
"tag:isrd.isi.edu,2016:foreign-key": {
  "journal_pattern": "",
  "author_pattern": "",
  "title_pattern": ""
  "year_pattern": "",
  "url_pattern": "",
  "id_pattern": "",
  "template_engine": "",
  "waitfor": [] // ?
}

This annotation is used for generating the citation dialog that we are showing after clicking on "share" button in record page. Supporting pseudo-columns in this annotation is actually one of the requested features.
From ermrestjs/chaise stand point, adding this should be relatively simple. The only issue here would be the UX. If a citation definition relies on an aggregate, we should either hide the share button or disable it, until we have the aggregate data.
2. Column display
"tag:isrd.isi.edu,2016:column-display": {
  "context": {
    "pre_format": "",
    "column_order": [],
    "markdown_pattern": "",
    "template_engine": "",
    "waitfor": [] // does this make sense?
  }
}

3. Key display
If you use a key constraint definition in your visible-columns, we are going to show a self-link to that row. Using this annotation, you can change this heuristic.
"tag:isrd.isi.edu,2016:key-display": {
  "context": {
    "column_order": [],
    "markdown_pattern": "",
    "template_engine": "",
     "waitfor": [] // does this make sense?
  }
}

4. Table display
This annotation is used for two purposes (based on different context):

row-name: The row-name is heavily used in different contexts. For example the heuristics for showing a ForeignKey Pseudo-column, is using the table's row-name. So this annotation is used outside the main table that this is defined for. Therefore the waitfor definition might be confusing.

"tag:isrd.isi.edu,2016:table-display": {
  "row_name": {
    "row_markdown_pattern": "",
    "template_engine": "",
    "waitfor": [] // ?
  }
}

markdown display of inline/related tables in record page. This has the same issue as the other use case. Assuming M is the name of the main table and R is the related table. When we're showing table R in the related/inline section, we're using the table-display that is defined on table R to generate the markdown display for us. Since this is done in context of table M, the active list is based on M but the annotation is defined on table R and therefore it doesn't make sense for its waitfor to use the active list of M.

"tag:isrd.isi.edu,2016:table-display": {
  "compact": {
    "row_order": [],
    "page_size": 25,
    "hide_column_headers": false,
    "collapse_toc_panel": false,
    "separator_markdown": "",
    "prefix_markdown": "",
    "suffix_markdown": "",
    "row_markdown_pattern": "",
    "page_markdown_pattern": "",
    "template_engine": "",
    "waitfor": [] // which active list? M? R?
  }
}

Compare this to the case of defining the markdown_pattern and waitfor directly in the visible-foreign-keys definition, which is in context of M and it makes sense that the waitfor is written based on active list of M.
"M": {
  "annotations": {
    "tag:isrd.isi.edu,2019:source_definitions": {
      "sources": {
        "key1": {// some definition }
      },
      "tag:isrd.isi.edu,2016:visible-foreign-keys": {
        "detailed": [
          {
             "source": [// path to the related table R ],
             "display": {
               "markdown_pattern": "",
               "template_engine": ""
             },
            "waitfor": ["key1"] // based on M's source definitions and not Rs
           }
        ]
      }
    }
  }
},
"A": {
  "annotations": {
    "tag:isrd.isi.edu,2016:table-display": {
      "*": {
        "row_markdown_pattern": "" // has access to A data and not M
      }
    }
  }
}

5. Asset url pattern
"tag:isrd.isi.edu,2017:asset" : {
  "browser_upload": false,
  "filename_column": "",
  "byte_count_column": "",
  "md5": "",
  "sha256": "",
  "sha256": "",
  "filename_ext_filter": [],
  "url_pattern": "",
  "template_engine": "",
  "waitfor": [] // ?
}

Currently in the url_pattern you cannot even access the $fkeys. The main problem is that we are generating url_pattern in create mode based on the row data. Therefore the data for the tables that have relationship to the given row are still unspecified. I'm not sure how this can even work.
6. Foreignkey domain filter pattern
"tag:isrd.isi.edu,2016:foreign-key": {
  "from_name": "",
  "to_name": "",
   "display": {
    "context": {
      "column_order": []
    }
   },
  "domain_filter_pattern": "",
  "template_engine": "",
  "waitfor": [] // ?
}

This has the same issue as asset's url_pattern. Since this is used in create mode too, the data for the tables that have relationship to the given row are still unspecified. I'm not sure how this can even work.

We had a discussion about this. The following are summary of what we agreed on.
Citation:

Should be implemented.
UX should be discussed.

Column Display, Key Display:

Should be implemented.

Table Display:

We should be able to allow wait_for in this annotation.
What the data-modelers will define in this list are sources that are defined for the current table and not the parent table. Therefore it won't be possible to allow them to access the active-list of main table.
We can change the syntax of wait_for to allow access to the parent, but that has its own issues as it will make the syntax very difficult to understand. Therefore we decided to not take this approach.
We should also continue allowing them access to the parent's main entity data in the page_markdown_pattern.

Asset url pattern, Foreign key domain filter pattern:

These annotations are used in entry contexts where the data might not be available.
There's a current usecase that we want to use an all-outbound path in the asset url_pattern.
With each user input we should send request for any active-list element that has a path (even the outbounds). To mitigate this issue, we should change how we're processing the wait_for list. The input columns (normal column or foreign key column) that will change the computed value of this template must be listed in the wait_for list. Then we will use the wait_for list to figure out which requests we have to send.
Currently recordedit doesn't have any flow-control which we have to add.

The first implementation of this feature has been added: ermrestjs PR / chaise PR.
We should be able to use pseudo-columns in the display setting for pseudo-columns in compact context.
The next steps are:

[ ] Supporting wait_for in visible-column and visible-foreign-keys in detailed.
[ ] Supporting wait_for in citation annotation.
[ ] Supporting wait_for in column-display and key-display.

When we were talking about this feature we didn't mention how this would be useful in faceting. We recently came up with a use case for this.
In this table we currently are showing a facet for Gene_Expression:Marker_Gene_Publication table, but the RID is not very useful to the users. What they would prefer to see is the combination of the following values:

Gene ID: Which comes from Common:Gene table that the Marker_Gene_Publcation table has foreign key to.
Anatomy ID: Which comes from Vocabulary:Anatomy table that the Marker_Gene_Publcation table has foreign key to.
Stage: Which comes from Vocabulary:Developmental_Stage table that the Marker_Gene_Publcation table has foreign key to.

There are two different solutions for this:

Modifying the row-name to be based on these three values. And since we're showing the row-name in the facet panel that should solve the issue. This means that data-modelers should be able to use the foreignkeys in the table-display annotation, or should be able to define their own list of wait_for. The only issue here would be the paths that might have inbound direction in them.

Allow display setting in the facet definition. This means that they should be able to define wait_for as well. This would give more flexibility compared to the other solution, but it still has the same issue of dealing with inbound paths.

After discussing briefly about this, we think that we should start supporting pseudo-columns without any source definition. In this case we might want to check for markdown_name and markdown_pattern,  and invalidate the pseudo-column definition if these two are missing.

While we were discussing about wait_for, we didn't specify which types of source definitions are allowed in it. So technically you can have the same entity set that is visible in the record page (either inline or related) as part of the wait_for of other columns. But the visible entity sets are currently displayed as tables and the user can interact with them (change the page, page size, or sort). Because of this, we had a discussion about whether we should even allow these types of source definitions in the wait_for.
We have three options of dealing with entity sets in wait_for definition:

Upgrade them to array_d aggregate.
Ignore them.
Use them as-is. Which means sending entity set requests for them.

The first option is not feasible and can be bad for performance. So in the following, I will summarize how the other two options compare:
-If we go with "as-is" option, we should send different requests for the entity sets that are in wait_for and the ones that are visible. As I mentioned in the previous paragraph users can interact with visible entity sets and if we send one request this means that we should keep them in sync. But keeping them in sync is confusing, so we're treating them differently. This can hurt the performance and also requires extra logic in the code.

If we ignore them, it is different from how we're treating them in the visible-columns itself. It might be confusing to allow them in the context, but not as part of wait_for in that context.

With "as-is", since we're going to send entity request, you can also access the foreign key data as well. Although this could hurt the performance when the table has too many outbound foreign keys.

Therefore, it makes sense to eventually go with the third option if we find use cases for it. As a starting step, we can just ignore these types of sources from the wait_for completely.

After making changes to the code I realized supporting entity sets should not be an issue and we decided to include it in the next implementation.
We also had a discussion about the priority of requests that we're sending in the record page. The request for getting the main columns and all-outbound is done prior to any other requests, so it's not part of our priority discussion and assumption is that this request has to be done before anything else. Currently, in record page, we have a bucket list of requests. We first send the request for all the inline tables, and then all the aggregates. We're going to remove that.
For the main part of the page, the requests will be sent from top to bottom depending on the type of the column and what's in the wait_for.

First, we're going to traverse the list of visible-columns from top to bottom and if the column is inline without any wait_for, or has only entity sets as part of its wait_for; we're going to send the requests for them (and their wait_for list definition).
Secondly, we're going to traverse the list of visible-columns and if the column is aggregate, or has aggregate in its wait_for; we're going to send the requests for them (and their wait_for list definition).

To demonstrate this, assume that the following is the visible-columns definition (columns named es are entity sets and agg are aggregates):
i1 (wait_for: agg1, agg2)
i2 (wait_for: es1, es3, agg1, agg3)
i3 (wait_for: es1, es2)
agg4
es4

Then the following will be the order of sending requests:
(i3, es1, es2), (es4), (i1, agg1, agg2), (i2, es3, agg3), (es4)

For the related section, since we're showing the tables from top to bottom, we should send the requests top to bottom as well (regardless of their types), so in that example this will be the order of requests:
(i1, agg1, agg2), (i2, es1, es3, agg3), (i3, ess), es4

We have a discussion about supporting wait_for on column and key display and decided not to add it to those annotations. For the reasons stated below:

Allowing data-modelers to define wait_for in these annotations doesn't reduce the amount of work that they need to do. They can achieve the same thing by just defining the markdown_pattern and wait_for in the source definition that is used in the visible-columns annotation.

The column display is used to generate the value of all-outbound scalar columns. So assume that we're getting the data for table S:M, and this is what you have in your visible-columns annotation:

"compact": [
  {"source": [{"outbound": ["s", "fk_from_M_to_F1"]}, "col"]}
]

Then to get the value of this pseudo-column, we're going to use the column-display of col column in the F1 table. Now if we allow data-modelers to define a wait_for in this column-display, the wait_for is defined based on F1 table; but in this case, we want to use it in the context of table M. The wait_for might be using multiple sources defined on F1. So if we actually want to support this, we have to add the path from M to F1 to all the sources defined in the active list of F1. This can be incorrect and might extra issues as there might be a loop in the produced path. Therefore we shouldn't try to this this.

The further part of the changes that are described in this issue have been merged with master. This includes

Addition of VirtualColumns
Allowing wait_for in detailed context of visible-columns and visible-foreign-keys
Allowing wait_for in citation annotation.

In a recent annotation change that @bugacov is working on for facebase, he mentioned a use case that could benefit from supporting aggregates in table-display annotation.

Click here for more information about the issue
Desired behavior
To simplify the explanation, let's assume that we're focused on table A on the record page. This table has a many-to-many relationship to table B. And table B has a many-to-many relationship to table C. We're showing table B in the related table section. Now in the custom-display mode, for each row in table B, we want to show the applicable rows in table C. Something like the following:
Title: Table B row 1
Available Cs: C1 C2

Title: Table B row 2
Available Cs: C3

Title: Table B row 3
Available Cs: C1 C3 C4 C7

Current solution
Since all the aggregates that are written for the record page are starting from table A, we cannot simply write an aggregate definition that goes from A to C. That would give us the same result for the listed Available Cs. Therefore, in the current solution, we're also adding a condition to make sure applicable rows are displayed, so something like:
"source-definitions": {
  "sources": {
    "aggregate-col": {
      "source": [], // path from A to C
      "entity": true,
      "aggregate": "array_d"
    }
  }
},
"visible-fks": {
  "source": [..], // path from A to B
  "markdown_pattern": "{{#each $self}}Title: {{this.Title}}\n Available Cs: {{#each ../aggregate-col}}{{#if (eq this.values.some_col_in_c ../values.som_col_in_B) }}{{this.values.C_Name}}{{/if}}{{/each}}\n{{/each}}"
},

(so two loops inside each other with an if condition)
This solution works but is not ideal,

We have to filter on the client-side and it only works in this case. In this case, we know that the number of rows is small, and also because of the model structure, there's a column that we can filter based on. This might not be available in other models.
Because of the if condition, we cannot easily show a comma in between the results (we don't know which one is the last, so we cannot conditionally hide the added comma after the last element.)

Better solution
The better solution would be having aggregates in table-display annotation. This way, we could write table-display annotation for table B that has aggregates that start from table B. Then we can simply just loop through the result without any additional condition.


Magellan on how to page active state issue

Scrolling about ~ 400px past magellan destination id causes is-active class to be removed even though scrolling is still within correct section.

Also throwing errors in console as scrolling. 909 by mid page

I believe this is because there are many more data-magellan-target elements in the page than in the magellan... was your intent to add those to the nav? Or should I remove them?

That was it - thanks!


The garbage collector and autogenerated types are causing a runtime panic

Autocomplete in LSP is not working in many cases. It seems to be using an older version of the token map, as I see this error in the LSP logs when it doesn’t work:
thread '<unnamed>' panicked at sway-core/src/concurrent_slab.rs:90:14:
no entry found for key

concurrent_slab.rs:
    pub fn get(&self, index: usize) -> Arc<T> {
        let inner = self.inner.read().unwrap();

        let value = inner.get(&index).unwrap_or_else(|| {
            let backtrace = std::backtrace::Backtrace::force_capture();
            eprintln!("backtrace: {:#?}", backtrace);
            panic!("Failed to get value from index: {}", index);
        });

        value.clone()
    }

Backtrace [
{ fn: "std::backtrace_rs::backtrace::libunwind::trace", file: "/rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/../../backtrace/src/backtrace/libunwind.rs", line: 104 },
{ fn: "std::backtrace_rs::backtrace::trace_unsynchronized", file: "/rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/../../backtrace/src/backtrace/mod.rs", line: 66 },
{ fn: "std::backtrace::Backtrace::create", file: "/rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/backtrace.rs", line: 331 },
{ fn: "std::backtrace::Backtrace::force_capture", file: "/rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/backtrace.rs", line: 313 },
{ fn: "sway_core::concurrent_slab::ConcurrentSlab::get" },
{ fn: "sway_core::semantic_analysis::namespace::trait_map::TraitMap::insert_for_type" },
{ fn: "sway_core::semantic_analysis::namespace::trait_map::TraitMap::check_if_trait_constraints_are_satisfied_for_type" },
{ fn: "sway_core::semantic_analysis::ast_node::declaration::auto_impl::AutoImplAbiEncodeContext::auto_impl_abi_encode" },
{ fn: "sway_core::semantic_analysis::module::::type_check" },
{ fn: "sway_core::semantic_analysis::program::::type_check" },
{ fn: "sway_core::parsed_to_ast" },
{ fn: "sway_core::compile_to_ast" },
{ fn: "forc_pkg::pkg::check" },
{ fn: "sway_lsp::core::session::compile" },
{ fn: "sway_lsp::core::session::parse_project" },
{ fn: "std::sys_common::backtrace::__rust_begin_short_backtrace" },
{ fn: "core::ops::function::FnOnce::call_once{{vtable.shim}}" },
{ fn: "<alloc::boxed::Box<F,A> as core::ops::function::FnOnce>::call_once", file: "/rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/alloc/src/boxed.rs", line: 2007 },
{ fn: "<alloc::boxed::Box<F,A> as core::ops::function::FnOnce>::call_once", file: "/rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/alloc/src/boxed.rs", line: 2007 },
{ fn: "std::sys::unix::thread::Thread::new::thread_start", file: "/rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/sys/unix/thread.rs", line: 108 },
{ fn: "__pthread_start" },
]
thread '' panicked at sway-core/src/concurrent_slab.rs:94:13:

I've been digging into this, it actually isn't caused by auto complete, it just so happens that auto complete LSP request is triggered when a key is pressed.
It appears this only started happening after #5306 was introduced. There is a conflict with how the garbage collection is operating and how types are constructed in the below functions.
pub fn auto_impl_abi_encode(&mut self, decl: &ty::TyDecl) -> Option<TyAstNode> {
    match decl {
        TyDecl::StructDecl(_) => self.struct_auto_impl_abi_encode(decl),
        TyDecl::EnumDecl(_) => self.enum_auto_impl_abi_encode(decl),
        _ => None,
    }
}

We should have had a CI test to catch this when the garbage collector PR was implemented in #5251. However, at that time, we were only performing GC every 10th keystroke and it was overloading the stack in CI. Now that we have reduced this to every 3rd keystroke it seems to be fine for CI. I've just put up a PR https://github.com/FuelLabs/sway/pull/5704 that can recreate this crash. Hopefully it will help debug how to resolve the underlying issue, and also prevent this sort of bug to creep through in the future.
Here is a stack trace of the error that is happening for reference. It's getting triggered by the .get call below at line 738 in trait_map.rs
let traitItems = map_trait_items
    .clone()
    .into_iter()
    .map(|(name, item)| match &item {
        ty::TyTraitItem::Fn(decl_ref) => {
            let mut decl = (*decl_engine.get(decl_ref.id())).clone();

thread '<unnamed>' panicked at sway-core/src/concurrent_slab.rs:90:14:
no entry found for key
stack backtrace:
   0: rust_begin_unwind
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:645:5
   1: core::panicking::panic_fmt
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panicking.rs:72:14
   2: core::panicking::panic_display
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panicking.rs:178:5
   3: core::panicking::panic_str
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panicking.rs:152:5
   4: core::option::expect_failed
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/option.rs:1985:5
   5: core::option::Option<T>::expect
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/option.rs:894:21
   6: <std::collections::hash::map::HashMap<K,V,S> as core::ops::index::Index<&Q>>::index
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/collections/hash/map.rs:1341:23
   7: sway_core::concurrent_slab::ConcurrentSlab<T>::get
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/concurrent_slab.rs:90:14
   8: <sway_core::decl_engine::engine::DeclEngine as sway_core::decl_engine::engine::DeclEngineGet<sway_core::decl_engine::id::DeclId<sway_core::language::ty::declaration::function::TyFunctionDecl>,sway_core::language::ty::declaration::function::TyFunctionDecl>>::get
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/decl_engine/engine.rs:89:17
   9: sway_core::semantic_analysis::namespace::trait_map::TraitMap::filter_by_type_inner::{{closure}}
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/namespace/trait_map.rs:739:50
  10: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &mut F>::call_once
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/ops/function.rs:305:13
  11: core::option::Option<T>::map
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/option.rs:1072:29
  12: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::next
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/iter/adapters/map.rs:103:26
  13: <im::hash::map::HashMap<K,V,S> as core::iter::traits::collect::FromIterator<(K,V)>>::from_iter
             at /Users/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/im-15.1.0/./src/hash/map.rs:1982:23
  14: core::iter::traits::iterator::Iterator::collect
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/iter/traits/iterator.rs:2054:9
  15: sway_core::semantic_analysis::namespace::trait_map::TraitMap::filter_by_type_inner
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/namespace/trait_map.rs:733:51
  16: sway_core::semantic_analysis::namespace::trait_map::TraitMap::filter_by_type
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/namespace/trait_map.rs:603:9
  17: sway_core::semantic_analysis::namespace::trait_map::TraitMap::insert_for_type
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/namespace/trait_map.rs:450:21
  18: sway_core::semantic_analysis::namespace::trait_map::TraitMap::check_if_trait_constraints_are_satisfied_for_type::{{closure}}
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/namespace/trait_map.rs:1095:21
  19: sway_error::handler::Handler::scope
             at /Users/josh/Documents/rust/fuel/sway/sway-error/src/handler.rs:60:27
  20: sway_core::semantic_analysis::namespace::trait_map::TraitMap::check_if_trait_constraints_are_satisfied_for_type

also, if i add the following eprintln!("decl_ref: {:#?}", decl_ref.name().span()); before it crashes, i get
decl_ref: Span {
    src (ptr): 0x0000000128209020,
    source_id: None,
    start: 0,
    end: 0,
    as_str(): "",
}

It seems that some of these dummy spans are slipping in which the GC see's and clears from the engines. I would have expected these to be recreated again on the next compilation but they don't seem to be?
Here are some more observations.
So it seems that possibly a TyFunctionDecl is being cleared from the DeclEngine during GC that it still expects to be there.
So If i then don’t remove ``TyFunctionDecls during GC and then run again it now crashes when trying to access TyImplTraits. I also get it with TyStructDecl&&TyAbiDecl`
8: <sway_core::decl_engine::engine::DeclEngine as sway_core::decl_engine::engine::DeclEngineGet<sway_core::decl_engine::id::DeclId<sway_core::language::ty::declaration::impl_trait::TyImplTrait>,sway_core::language::ty::declaration::impl_trait::TyImplTrait>>::get

If I disable clearing the type engine and only clear the decl engine with the below then this seems to work.
decl_engine_clear_module!(
    // function_slab, ty::TyFunctionDecl;
    trait_slab, ty::TyTraitDecl;
    trait_fn_slab, ty::TyTraitFn;
    trait_type_slab, ty::TyTraitType;
    // impl_trait_slab, ty::TyImplTrait;
    // struct_slab, ty::TyStructDecl;
    storage_slab, ty::TyStorageDecl;
    // abi_slab, ty::TyAbiDecl;
    constant_slab, ty::TyConstantDecl;
    enum_slab, ty::TyEnumDecl;
    type_alias_slab, ty::TyTypeAliasDecl;
);

So the above seems to be 1 issue. If I comment out clearing the decl engine and just do the type engine then we encounter a whole seperate problem.
thread '<unnamed>' panicked at sway-core/src/concurrent_slab.rs:90:14:
no entry found for key
stack backtrace:
   0: rust_begin_unwind
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:645:5
   1: core::panicking::panic_fmt
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panicking.rs:72:14
   2: core::panicking::panic_display
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panicking.rs:178:5
   3: core::panicking::panic_str
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panicking.rs:152:5
   4: core::option::expect_failed
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/option.rs:1985:5
   5: core::option::Option<T>::expect
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/option.rs:894:21
   6: <std::collections::hash::map::HashMap<K,V,S> as core::ops::index::Index<&Q>>::index
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/collections/hash/map.rs:1341:23
   7: sway_core::concurrent_slab::ConcurrentSlab<T>::get
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/concurrent_slab.rs:90:14
   8: sway_core::type_system::engine::TypeEngine::get
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/type_system/engine.rs:92:9
   9: sway_core::semantic_analysis::ast_node::expression::typed_expression::method_application::monomorphize_method_application
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/ast_node/expression/typed_expression/method_application.rs:599:19
  10: sway_core::semantic_analysis::ast_node::expression::typed_expression::method_application::type_check_method_application
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/ast_node/expression/typed_expression/method_application.rs:363:5
  11: sway_core::semantic_analysis::ast_node::expression::typed_expression::<impl sway_core::language::ty::expression::expression::TyExpression>::type_check
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/ast_node/expression/typed_expression.rs:264:17
  12: sway_core::semantic_analysis::ast_node::<impl sway_core::language::ty::ast_node::TyAstNode>::type_check
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/ast_node/mod.rs:148:33
  13: sway_core::semantic_analysis::ast_node::code_block::<impl sway_core::language::ty::code_block::TyCodeBlock>::type_check::{{closure}}
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/ast_node/code_block.rs:23:17
  14: core::ops::function::impls::<impl core::ops::function::FnMut<A> for &mut F>::call_mut
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/ops/function.rs:294:13
  15: <core::slice::iter::Iter<T> as core::iter::traits::iterator::Iterator>::find_map
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/slice/iter/macros.rs:319:38
  16: <core::iter::adapters::filter_map::FilterMap<I,F> as core::iter::traits::iterator::Iterator>::next
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/iter/adapters/filter_map.rs:62:9
  17: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter_nested::SpecFromIterNested<T,I>>::from_iter
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/alloc/src/vec/spec_from_iter_nested.rs:26:32
  18: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/alloc/src/vec/spec_from_iter.rs:33:9
  19: <alloc::vec::Vec<T> as core::iter::traits::collect::FromIterator<T>>::from_iter
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/alloc/src/vec/mod.rs:2753:9
  20: core::iter::traits::iterator::Iterator::collect
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/iter/traits/iterator.rs:2054:9
  21: sway_core::semantic_analysis::ast_node::code_block::<impl sway_core::language::ty::code_block::TyCodeBlock>::type_check
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/ast_node/code_block.rs:18:34
  22: sway_core::semantic_analysis::ast_node::declaration::function::<impl sway_core::language::ty::declaration::function::TyFunctionDecl>::type_check_body
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/ast_node/declaration/function.rs:200:20
  23: sway_core::semantic_analysis::ast_node::declaration::function::<impl sway_core::language::ty::declaration::function::TyFunctionDecl>::type_check
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/ast_node/declaration/function.rs:36:9
  24: sway_core::semantic_analysis::ast_node::declaration::impl_trait::type_check_impl_method
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/ast_node/declaration/impl_trait.rs:996:9
  25: sway_core::semantic_analysis::ast_node::declaration::impl_trait::type_check_trait_implementation
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/ast_node/declaration/impl_trait.rs:814:39
  26: sway_core::semantic_analysis::ast_node::declaration::impl_trait::<impl sway_core::language::ty::declaration::impl_trait::TyImplTrait>::type_check_impl_trait
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/ast_node/declaration/impl_trait.rs:162:33
  27: sway_core::semantic_analysis::ast_node::declaration::declaration::<impl sway_core::language::ty::declaration::declaration::TyDecl>::type_check
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/ast_node/declaration/declaration.rs:171:27

The issue is that auto generated code, or anything using Span:dummy(), does not have a source_id nor a module_id and it is being collected in every gc. We just need to retain them.

I did suspect that and replaced all of the Span::dummy() 's with a dummy span containing a source_id = Some(SourceId::reserved()) so that it wouldn't get cleared by the GC. However, I was then running into other compiler panics with unify_check.
thread '<unnamed>' panicked at sway-core/src/concurrent_slab.rs:90:14:
no entry found for key
stack backtrace:
   0: rust_begin_unwind
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:645:5
   1: core::panicking::panic_fmt
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panicking.rs:72:14
   2: core::panicking::panic_display
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panicking.rs:178:5
   3: core::panicking::panic_str
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panicking.rs:152:5
   4: core::option::expect_failed
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/option.rs:1985:5
   5: core::option::Option<T>::expect
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/option.rs:894:21
   6: <std::collections::hash::map::HashMap<K,V,S> as core::ops::index::Index<&Q>>::index
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/collections/hash/map.rs:1341:23
   7: sway_core::concurrent_slab::ConcurrentSlab<T>::get
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/concurrent_slab.rs:90:14
   8: sway_core::type_system::engine::TypeEngine::get
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/type_system/engine.rs:100:9
   9: sway_core::type_system::unify::unify_check::UnifyCheck::check_inner
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/type_system/unify/unify_check.rs:232:26
  10: sway_core::type_system::unify::unify_check::UnifyCheck::check_multiple
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/type_system/unify/unify_check.rs:662:17
  11: sway_core::type_system::unify::unify_check::UnifyCheck::check_inner
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/type_system/unify/unify_check.rs:270:24
  12: sway_core::type_system::unify::unify_check::UnifyCheck::check
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/type_system/unify/unify_check.rs:220:9
  13: sway_core::semantic_analysis::namespace::trait_map::TraitMap::filter_by_type::{{closure}}
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/namespace/trait_map.rs:599:53
  14: sway_core::semantic_analysis::namespace::trait_map::TraitMap::filter_by_type_inner
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/namespace/trait_map.rs:725:27
  15: sway_core::semantic_analysis::namespace::trait_map::TraitMap::filter_by_type
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/namespace/trait_map.rs:603:9
  16: sway_core::semantic_analysis::namespace::trait_map::TraitMap::insert_for_type
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/namespace/trait_map.rs:450:21
  17: sway_core::semantic_analysis::type_check_context::TypeCheckContext::insert_trait_implementation_for_type
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/type_check_context.rs:1536:9
  18: sway_core::semantic_analysis::type_check_context::TypeCheckContext::find_method_for_type
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/type_check_context.rs:1177:17
  19: sway_core::semantic_analysis::ast_node::expression::typed_expression::method_application::resolve_method_name
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/ast_node/expression/typed_expression/method_application.rs:507:28
  20: sway_core::semantic_analysis::ast_node::expression::typed_expression::method_application::type_check_method_application
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/ast_node/expression/typed_expression/method_application.rs:52:49
  21: sway_core::semantic_analysis::ast_node::expression::typed_expression::<impl sway_core::language::ty::expression::expression::TyExpression>::type_check
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/ast_node/expression/typed_expression.rs:264:17
  22: sway_core::semantic_analysis::ast_node::<impl sway_core::language::ty::ast_node::TyAstNode>::type_check
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/ast_node/mod.rs:148:33
  23: sway_core::semantic_analysis::ast_node::code_block::<impl sway_core::language::ty::code_block::TyCodeBlock>::type_check::{{closure}}
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/ast_node/code_block.rs:23:17
  24: core::ops::function::impls::<impl core::ops::function::FnMut<A> for &mut F>::call_mut
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/ops/function.rs:294:13
  25: <core::slice::iter::Iter<T> as core::iter::traits::iterator::Iterator>::find_map
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/slice/iter/macros.rs:319:38
  26: <core::iter::adapters::filter_map::FilterMap<I,F> as core::iter::traits::iterator::Iterator>::next
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/iter/adapters/filter_map.rs:62:9
  27: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter_nested::SpecFromIterNested<T,I>>::from_iter
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/alloc/src/vec/spec_from_iter_nested.rs:26:32
  28: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/alloc/src/vec/spec_from_iter.rs:33:9
  29: <alloc::vec::Vec<T> as core::iter::traits::collect::FromIterator<T>>::from_iter
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/alloc/src/vec/mod.rs:2753:9
  30: core::iter::traits::iterator::Iterator::collect
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/iter/traits/iterator.rs:2054:9
  31: sway_core::semantic_analysis::ast_node::code_block::<impl sway_core::language::ty::code_block::TyCodeBlock>::type_check
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/ast_node/code_block.rs:18:34
  32: sway_core::semantic_analysis::ast_node::declaration::function::<impl sway_core::language::ty::declaration::function::TyFunctionDecl>::type_check_body
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/ast_node/declaration/function.rs:200:20
  33: sway_core::semantic_analysis::ast_node::declaration::function::<impl sway_core::language::ty::declaration::function::TyFunctionDecl>::type_check
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/ast_node/declaration/function.rs:36:9
  34: sway_core::semantic_analysis::ast_node::declaration::impl_trait::type_check_impl_method
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/ast_node/declaration/impl_trait.rs:996:9
  35: sway_core::semantic_analysis::ast_node::declaration::impl_trait::type_check_trait_implementation
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/ast_node/declaration/impl_trait.rs:814:39
  36: sway_core::semantic_analysis::ast_node::declaration::impl_trait::<impl sway_core::language::ty::declaration::impl_trait::TyImplTrait>::type_check_impl_trait
             at /Users/josh/Documents/rust/fuel/sway/sway-core/src/semantic_analysis/ast_node/declaration/impl_trait.rs:238:33

Should be addressed in #5813


how to Building a Custom Module?

i need add a music button.
i can't find How to add a format use the ng-quill!?

like you would do it with plain quilljs ;)
https://quilljs.com/guides/building-a-custom-module/
or configure your formats:
https://quilljs.com/guides/how-to-customize-quill/#content-and-formatting
register your module/format on the global Quill object and after that you can use it ;)
You can configure your toolbar through modules input of ng-quill-editor component. There you can pass an javascript object with the configuration of your toolbar or other modules.
Or you can build up your own toolbar directly with html-code with the ng-quill-toolbar component
https://github.com/KillerCodeMonkey/ng-quill#usage
An example of that you can find here: https://github.com/KillerCodeMonkey/ng-quill/blob/develop/demo.html

tanks!~


[Spike] Investigate How to Use Okta Instead of Auth0 for Authentication

Timebox:
5 day
Business Context:
Hawaii's IT department demands that we support Multi-Factor Authentication (hereafter referred to as MFA). Auth0 supports MFA but only on a higher level plan that costs $240 dollars per month, which is not cool. Okta has a "developer" account that supports enough users with MFA that it would work for Hawaii's use-case. Therefore we would like to explore the viability of making Okta an auth option for complaint-manager (without forcing New Orleans to switch over)
As a Hawaii IT person
I want the correctional system oversight commission to only access confidential case information using an app that supports MFA
So that our precious data is more secure
As a Hawaii CSOC person with the training to pay for things
I want to pay less than $240 per month for an auth system that will be supporting less than 10 users
So that I have money left over to actually do oversight things
As a NOIPM employee
I want to be able to continue using Auth0
So that I don't have to setup new accounts
As a New org looking to use complaint-manager
I want to have options when choosing how to do authorization/authentication on the app
So that I have flexibility in meeting compliance requirements
In Scope

Setup Okta developer account for team use (link)
Investigate what it would take to achieve what we currently achieve in Auth0 using Okta, this includes:

Redirect to an auth page when the user accesses a page that requires auth but is not logged in
Get all registered users
Return specific permissions for the user (custom scopes is another term that Okta may use) that allow us to prohibit some users from doing some things

Investigate the feasibility of swapping Auth0 with Okta on a per Org basis
Write stories

Out of Scope

Doing any of this stuff (I mean, if you don't know what will work until you do it, then go ahead and do it, but don't strain yourself)

Open Questions

Acceptance Criteria

Scenario:
Given
When
Then

Scenario:
Given
When
Then

Mockups
Checklist (should be reviewed before grooming as the BA or Pair are writing the card—NOT reviewed for the first time at grooming)

[ ] Ensure to include all necessary mockups to this card.
[ ] Discuss what success/failure user feedback messages would be present, if any occur (front end/back end).
[ ] Discuss Feature Flag: Where could a development flag go to flag off incomplete work? Do we want to keep the flag long-term?
[ ] If this card is part of a sequence of cards, discuss if this card should be blocked until the testing of previous cards in the sequence have been finished.
[ ] Have we added edge cases as ACs that we're considered from a QA perspective
[ ] Should the new functionalities be offered only to users with certain permissions?
[ ] How should this functionality differ between different orgs, and if it does differ, what is the hingepoint we should use for that functionality?

Notes:

Server Side
jwtCheck and verifyUserNickname need to be examined to make sure that jwtCheck can parse an okta oauth token (if not we can use @okta/jwt-verifier when the auth provider is okta) and that we can map the okta username and permissions to nickname and permissions in verifyUserNickname

Front End
Use @okta/okta-react import the Security component into RootContainer or App.js and wrap it around the entire app (but only if Okta is enabled rather than Auth0) see below comment that will cover how we handle swapping those. Get the client id and issuer from clientConfig file in instance-files

Guide to mocking Okta stuff in front-end jest tests https://stackoverflow.com/questions/60876624/how-to-test-mock-out-react-hooks

Getting access to permissions on the front-end
Look in src/client/common/auth/Auth.js and make sure that it parses the Okta JWT properly to get the nickname and permissions (and pass them to the store). If it doesn't we may need branching logic (between Okta and Auth0) based on the auth provider that maps those values differently (or possibly uses a different jwt library altogether if necessary)

Login Process
We need to use the LoginCallback component provided by @okta/okta-react for our callback page (iff the auth provider is Okta), but we also need to get the jwt (using the HOC withOktaAuth or the hook useOktaAuth) and pass it through the Auth class (src/client/common/auth/Auth.js) so that we can break it down and get the nickname and permissions.
The hope is that we can use a built-in Okta login page that will magically implement MFA without telling us anything about it, and then redirect to us and we'll magically have access to the JWT token.

Get a list of all users
On the backend you can use the @okta/okta-sdk-nodejs library which has a function listUsers that will allow you to get those. We need to put branching logic in Auth0UserService (and rename it) that uses the listUsers function if the auth provider is Okta


sync events emission returns immediately

This is a Bug Report
For bug reports, please answer following questions:

What went wrong?
Sync behaviour does not match what was described at https://github.com/serverless/event-gateway/issues/478#issuecomment-405281407
I'm getting a status 202 response instead of the response from my Lambda function.
What did you expect should have happened?
Expected to receive response from my Lambda function.
What was the version you used?
event-gateway-sdk "version": "0.10.2"
serverless-event-gateway-plugin "version": "0.7.8"

Environment Information -----------------------------
     OS:                     darwin
     Node Version:           8.11.3
     Serverless Version:     1.32.0

Similar or dependent issues:

https://github.com/serverless/event-gateway/issues/478

To reproduce, I've setup a repo at https://github.com/johnlim/serverless-bugs/tree/sync-bug

clone the repo and checkout the branch sync-bug
npm i
enter the required tenant/app/service parameters in serverless.yml
sls deploy
make a http get request to the simulate endpoint

Thanks @johnlim will look into this and get back to you!

@sebito91 Thanks and please let me know if you need any assistance on this.

@sebito91 Hope all is well with you. Did you manage to reproduce the issue? Hope to hear from you soon.


Question: Is it possible to signify nothing is parsed after argument?

I'm writing a command line utility that is designed to wrap the execution of other commands (it will have arguments of it's own). It will be common that a user would want to do something like this: mycmd their_command -c -F. I know this is currently possible using -- to say mycmd -- bash -c 'some code'.
The problem I expect to happen will be that if the user wraps a command without arguments it will work fine (e.g. mycmd echo foo) but the behavior would be different when using a command with a flag (e.g. mycmd bash -c 'echo foo').
Would it be possible to have an argument that nothing is parsed after this or to require "--" be used? I'm guessing I could precheck os.Args to ensure "--" exists before moving on to further parsing.

This is actually a bug: what you are describing should be possible to implement using this spec string:
app.Spec = "-c -- CMD [ARG...]"

i.e. by using the -- operator in the spec string to tell mow.cli that after the -c option, parse everything as an argument and ignore options.
I implemented the first half of this logic in the spec parser but I forgot to implement the second half.
So thanks for spotting it ! The fix is under way.

Huh interesting. To give a little bit more on what I'm doing I currently have: app.Spec = "-- CMD [ARG...]". myapp echo foo will do as you would expect but myapp bash -c 'echo foo' errors with Error: Illegal option -c.
Is it possible that it would know that -c is actually part of the bash call? I'm guessing not easily.

Yep, your spec string is absolutely correct, and the fact that you get the error you mention is a bug that I'm trying to fix as we're speaking.

Awesome (and thank you)! Wasn't sure if we were on the same page.

The good news is that I located the origin of the bug and I have a rough idea on how to go about fixing it.
The bad news is that fixing it is going to require a fair chunk of work and rewriting parts of the parsing/normalization logic, so it might take a day or 2.
Thanks again for finding it and stay tuned.

Wonderful! Thanks for getting this fixed and keep up the good work.

Thanks !


Migrate from pnpm to bun

Make sure bun is used in:

[x] Earthly
[x] All package json
[x] build.rs script
[x] Make sure workspaces work

Roadblocks:
Recursive calling / package.json scripts
bun does not suppoort -r or --workspace. I want to call bun run only once from the top project, instead of repeating it in each folder. I could fix this by writing a custom script... But after trying a script I made it still doesn't work:
eslint ./src --ext .js,.jsx,.ts,.tsx

Oops! Something went wrong! :(

ESLint: 8.23.0

Error [ERR_REQUIRE_ESM]: require() of ES Module<EMAIL_ADDRESS>from<EMAIL_ADDRESS>not supported.
Instead change the require of<EMAIL_ADDRESS>in<EMAIL_ADDRESS>to a dynamic import() which is available in all CommonJS modules.
    at Object.<anonymous> (/Users/joep/dev/github/atomicdata-dev/atomic-server/browser/node_modules/.pnpm/eslint@8.23.0/node_modules/eslint/node_modules/find-up/node_modules/locate-path/node_modules/p-locate/node_modules/p-limit/index.js:2:15)

Maybe because eslintrc is ignored, because it's in the parent directory.
Still using vite build and tsc
One of the advantages of bun is that it has a server and compiler in one. I should be able to ditch vite and tsc.
PR Checklist:

[x] Link to related issues: closes #642 https://github.com/ngi-nix/ngipkgs/issues/15
[ ] Add changelog entry linking to issue, describe API changes
[x] Add tests (optional)
[x] (If new feature) add to description / readme

I think I won't explore this further, at least for now. Bun seems a bit too young to migrate to, and it isn't as trivial as I hoped.


Add JWS Domain object to the Athenz Domain custom resource

Please describe the problem that you are trying to solve
Update the Athenz Domain custom resource spec to support the JWS domain object.
Describe the solution you'd like
This issue is meant to introduce the first set of changes required for the Athenz Syncer to move to the new JWS Domain API endpoint.
The current Athenz Domain custom resource is using the SignedDomain object  which is populated by the results of the Athenz sys modified domain API response. We need to introduce the JWSDomain object in the AthenzDomainStatus object in order to store the results of the new JWS domain API response.
Once this change is made, the Athenz Domain custom resource must be regenerated using the kubernetes code-generator.
Additional context
Currently, the Athenz Syncer fetches the Athenz domain content using the ZMS sys modified domains API which returns the entire contents of the domain along with a key ID / signature which was used to sign this content. Due to the domain spec constantly changing, it is not feasible to use these signatures to validate this content as the API the client is on might be different than the ZMS server. For example, if ZMS is running with version v1.10.9 which contains a new field for the domain spec, and the client is running on v1.10.8 then the client will drop this new field during the json to object cast and the signature verification will fail.
In order to allow consumers of the Athenz Domain custom resource to correctly verify the signatures of the domain objects, a new API was introduced by Athenz which provides the contents of the domain as an JSON Web Signature (JWS) response (shown below).
{
  "payload": "Zm9vYmFyCg==.....",
  "header": {
    "keyid": "zms.key.3.0"
  },
  "signature": "YmFyZm9vCg==...",
  "protected": "YmFyCg==..."
}

As can be seen above, the payload is the content of the Athenz domain signed by the ZMS private key and ybase64 encoded. In order to verify and read the payload, the ZMS key (described by the keyid field) needs to be used to compare against the signature field.

Hey @mcieplak (again), I'd like to work on this one too if that's okay.

Hey, sure that would be great. Thanks!

Closing this issue as the PR has been merged. Thanks @patrasap0908 for your contribution!


[Feature Request] capability to render tabs from subheading

Currently, tabs can be created using list items only.
It would be nice if awesome CSS could create tabs out of subheadings as well.
# heading
<div class="tabbed">
## <b class="tab-title"> sub heading 1 </b>
Content of subheading 1
## <b class="tab-title"> sub heading 2 </b>
Content of subheading 2
</div>

Or something like this
<b class="tab-title">
### macOS dependencies
</b>

Messed this one up, will be creating a new PR with a better solution

@AdarshRawat1 Can you check if this works well?


How use as ES6 modules?

You can write tutorial?
I can`t clone all with submodules, you can create  start template project?  For example yo hexi-app MyApp

Hi, could any Git experts out there help us out with this?


Breaks don't display on all monitors Win7

Prerequisites

[x ] I'm using latest version: v0.19.1
[x ] I've checked Not displaying on all monitors Win10

Description
With breaks are shown on all monitors checked, my breaks only show on my primary monitor. This may be different from Not displaying on all monitors Win10 because I'm running Windows 7, not Windows 10.
Operating system:
Windows 7 Enterprise
Service Pack 1
Steps to Reproduce

Have a Windows 7 Enterprise system with two monitors, set to Extend these displays
In Stretchly, check the breaks are shown on all monitors checkbox
Wait for a break or microbreak to occur

Expected behavior:
Break or microbreak information should be shown on both monitors.
Actual behavior:
Break or microbreak information is shown only on primary monitor.
Reproduces how often: [What percentage of the time does it reproduce?]
Additional Information
Display settings:

Display 1: Resolution: 1920 x 1200, Orientation: Landscape
Display 2: Resolution: 1920 x 1200, Orientation: Landscape
Multiple displays : Extend these displays

This is a duplicate of #388 which was closed as this is an electron bug found here https://github.com/electron/electron/issues/16907

#388 specifically mentions Windows 10, and I'm on Windows 7. Do we know for sure that it also applies to 7? If so, I'm happy to close this.

As far as I can tell from electron...yes.

:-) <----- Me happily closing the issue.

Yeah, sorry about it ;/


fix duplicated list for issue #2134

What this PR does / why we need it?
Summary of your change
Please indicate you've done the following:

[ ] Made sure tests are passing and test coverage is added if needed.
[ ] Made sure commit message follow the rule of Conventional Commits specification.
[ ] Considered the docs impact and opened a new docs issue or PR with docs changes if needed.

Codecov Report
Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (67e1e74) 75.37% compared to head (b2ed6a6) 73.64%.

Files
Patch %
Lines

...main/java/com/alibaba/fastjson2/JSONPathMulti.java
75.00%
1 Missing and 2 partials :warning:

Additional details and impacted files
@@             Coverage Diff              @@
##               main    #2142      +/-   ##
============================================
- Coverage     75.37%   73.64%   -1.73%
+ Complexity    21637    20915     -722
============================================
  Files           634      622      -12
  Lines         85368    84631     -737
  Branches      18920    18721     -199
============================================
- Hits          64343    62325    -2018
- Misses        13109    14341    +1232
- Partials       7916     7965      +49

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Safari search bar typing issue

I've been experiencing a strange bug in Safari, but only when this extension is enabled. As I type a certain phrase ("mysql returns"), the address bar is cleared and seems to reset to the address of the current page. I can reliably reproduce this, even after restarting Safari and disabling & re-enabling the extension. I think it has something to do with the speed of my typing the phrase, which suggests to me that it's an issue with asynchronous code.
After trying it on a new tab page and on google.com, when I type that phrase and the behavior is triggered, I'm actually taken to the page shown in the video (on the PHP documentation site).
Here's a video showing the problem.
Extension version 2018.1.9, Safari 11.0.2, macOS 10.13.2, Late 2012 Mac mini. I'd be happy to provide more information if anyone wants to look into this bug further.

I also experience this issue with Firefox, though it only happens when I first open a browser window. New tabs are not affected, and if you wait a few seconds the issue does not occur, so it seems like (at least in my case) it's some kind of initialization thing.
Suggested URLs don't automatically get completed like they usually do, and sometimes the search gets totally cleared.

@tylermumford thanks for the video. It should be fixed in the most recent Safari version (2018-1-30). You might need to remove your old extension and get a new one from https://duckduckgo.com.

@davisdude I'm seeing that too. This is the extension loading https data on start up. I think @laurengarcia was already looking into fixing that.

Great, thank you so much. On first glance, the issue appears to be fixed. I'll update this thread if I encounter it again with a newer version of the extension.


feat: implement graceful error handling in operator package

Fixes #N/A
Description
This implements fail open logic within the operator package
How was this change tested?
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>2
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

0 of 64 (0.0%)  changed or added relevant lines in 1 file are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.3%) to 80.497%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/operator/operator.go
0
64
0.0%

Files with Coverage Reduction
New Missed Lines
%

pkg/controllers/nodeclaim/lifecycle/liveness.go
1
81.82%

Totals

Change from base Build<PHONE_NUMBER>5:
-0.3%

Covered Lines:
8420

Relevant Lines:
10460

💛  - Coveralls

/lgtm


Client Certs not working in xamarin.android, but does work with .NET Core 3.1

Describe the bug
Cross-posted: https://github.com/xamarin/xamarin-android/issues/4481
Connecting to mosquitto when mosquitto configured to use certificates fails when compiled as xamarin.android, but does work if compiled as a console application using .NET Core 3.1.
Which project is your bug related to?

Client

To Reproduce
Steps to reproduce the behavior:

Using this version of MQTTnet 3.0.9-rc1 (same issue when using 3.0.8)

See error:

Exception: MQTTnet.Exceptions.MqttCommunicationException: Authentication failed, see inner exception. ---> System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception. ---> System.Security.Cryptography.CryptographicException: Caught unhandled exception in MonoBtlsSslCtx.ProcessHandshake. ---> System.NullReferenceException: Object reference not set to an instance of an object.
at Mono.Btls.MonoBtlsSsl.SetPrivateKey (Mono.Btls.MonoBtlsKey key) [0x00006] in /Users/builder/jenkins/workspace/archive-mono/2019-10/android/release/mcs/class/System/Mono.Btls/MonoBtlsSsl.cs:214
at Mono.Btls.MonoBtlsContext.SetPrivateCertificate (Mono.Btls.X509CertificateImplBtls privateCert) [0x00011] in /Users/builder/jenkins/workspace/archive-mono/2019-10/android/release/mcs/class/System/Mono.Btls/MonoBtlsContext.cs:166
at Mono.Btls.MonoBtlsContext.SelectCallback (System.String[] acceptableIssuers) [0x0003a] in /Users/builder/jenkins/workspace/archive-mono/2019-10/android/release/mcs/class/System/Mono.Btls/MonoBtlsContext.cs:122
at Mono.Btls.MonoBtlsSslCtx.NativeSelectCallback (System.IntPtr instance, System.Int32 count, System.IntPtr sizes, System.IntPtr data) [0x00025] in /Users/builder/jenkins/workspace/archive-mono/2019-10/android/release/mcs/class/System/Mono.Btls/MonoBtlsSslCtx.cs:174
--- End of inner exception stack trace ---
at Mono.Btls.MonoBtlsObject.CheckLastError (System.String callerName) [0x00064] in /Users/builder/jenkins/workspace/archive-mono/2019-10/android/release/mcs/class/System/Mono.Btls/MonoBtlsObject.cs:120
at Mono.Btls.MonoBtlsContext.ProcessHandshake () [0x00032] in /Users/builder/jenkins/workspace/archive-mono/2019-10/android/release/mcs/class/System/Mono.Btls/MonoBtlsContext.cs:219
at Mono.Net.Security.MobileAuthenticatedStream.ProcessHandshake (Mono.Net.Security.AsyncOperationStatus status, System.Boolean renegotiate) [0x000da] in /Users/builder/jenkins/workspace/archive-mono/2019-10/android/release/mcs/class/System/Mono.Net.Security/MobileAuthenticatedStream.cs:715
at (wrapper remoting-invoke-with-check) Mono.Net.Security.MobileAuthenticatedStream.ProcessHandshake(Mono.Net.Security.AsyncOperationStatus,bool)
at Mono.Net.Security.AsyncHandshakeRequest.Run (Mono.Net.Security.AsyncOperationStatus status) [0x00000] in /Users/builder/jenkins/workspace/archive-mono/2019-10/android/release/mcs/class/System/Mono.Net.Security/AsyncProtocolRequest.cs:289
at Mono.Net.Security.AsyncProtocolRequest.ProcessOperation (System.Threading.CancellationToken cancellationToken) [0x000fc] in /Users/builder/jenkins/workspace/archive-mono/2019-10/android/release/mcs/class/System/Mono.Net.Security/AsyncProtocolRequest.cs:223
--- End of inner exception stack trace ---
at Mono.Net.Security.MobileAuthenticatedStream.ProcessAuthentication (System.Boolean runSynchronously, Mono.Net.Security.MonoSslAuthenticationOptions options, System.Threading.CancellationToken cancellationToken) [0x0025c] in /Users/builder/jenkins/workspace/archive-mono/2019-10/android/release/mcs/class/System/Mono.Net.Security/MobileAuthenticatedStream.cs:310
at MQTTnet.Implementations.MqttTcpChannel.ConnectAsync (System.Threading.CancellationToken cancellationToken) [0x00296] in :0
at MQTTnet.Internal.MqttTaskTimeout.WaitAsync (System.Func`2[T,TResult] action, System.TimeSpan timeout, System.Threading.CancellationToken cancellationToken) [0x000c2] in :0
at MQTTnet.Adapter.MqttChannelAdapter.ConnectAsync (System.TimeSpan timeout, System.Threading.CancellationToken cancellationToken) [0x00117] in :0
--- End of inner exception stack trace ---
at MQTTnet.Adapter.MqttChannelAdapter.WrapException (System.Exception exception) [0x00067] in :0
at MQTTnet.Adapter.MqttChannelAdapter.ConnectAsync (System

Mosquitto:

1585478267: OpenSSL Error[0]: error:140350E5:SSL routines:ACCEPT_SR_CERT:ssl handshake failure

Expected behavior
Connect without errors
Code snippet:
const SslProtocols sslProtocolVersion = SslProtocols.Tls12;

string currentPath = Path.Combine(Android.OS.Environment.ExternalStorageDirectory.AbsolutePath, Android.OS.Environment.DirectoryDownloads);
X509Certificate rootCert = X509Certificate.CreateFromSignedFile(Path.Combine(currentPath, rootCertName));
X509Certificate2 certificate = new X509Certificate2(Path.Combine(currentPath, userCertName), CertPrivKey);
UpdateStatusNonUI("Root Cert: '" + rootCert.Subject.ToString() + "'");
UpdateStatusNonUI("User Cert: '" + certificate.Subject.ToString() + "'");
UpdateStatusNonUI(userCertName + " has Private Key: '" + certificate.HasPrivateKey.ToString() + "'");

var TLSParameters = new MqttClientOptionsBuilderTlsParameters {
  UseTls = true,
  IgnoreCertificateChainErrors = false,
  IgnoreCertificateRevocationErrors = false,
  AllowUntrustedCertificates = false,
  SslProtocol = sslProtocolVersion,
  CertificateValidationCallback = (X509Certificate x, X509Chain y, SslPolicyErrors z, IMqttClientOptions o) => {
  return true;
  },
  Certificates = new List<X509Certificate> {
    rootCert,
    certificate
  },
};
UpdateStatusNonUI("TLS Parameters Set");

var options = new MqttClientOptionsBuilder()
  .WithClientId(clientId)
  .WithTcpServer(strMQTTServer, intMQTTPort)
  .WithCredentials(strMQTTUser, strMQTTPassword)
  .WithCleanSession()
  .WithTls(TLSParameters)
  .WithProtocolVersion(mqttProtocolVersion)
  .Build();
  UpdateStatusNonUI("Options Set");

  var mqttClient = new MqttFactory().CreateMqttClient();
  var MqttClientAuthenticateResult = await mqttClient.ConnectAsync(options);

Problem with MQTTnet or mono?

Since this is not supported in Xamarin yet, I guess, there's nothing we can do.

@johnjore  I agree with @SeppPenner . The exception is thrown inside the Mono implementation (while setting the private key).
If you have any updates or there is something we can do please let us know.

Hi, I know this bug is marked as closed, but I have randomly stumbled workaround by complete chance.
I've come across the same error while trying out MQTTNet with Xamarin Forms.
In the process of testing solutions, I've found this workaround:
When creating the Certificates list like it's shown in the Wiki I had the error:
[...]
Certificates = new List<X509Certificate>()
{
    caCert,
    clientCert,
}

System.Security.Cryptography.CryptographicException: Caught unhandled exception in MonoBtlsSslCtx.ProcessHandshake. ---> System.NullReferenceException: Object reference not set to an instance of an object.

BUT, I have no clue why, giving the clientCert first in the list gave me a successful connection in Xamarin:
[...]
Certificates = new List<X509Certificate>()
{
   clientCert,
   caCert,
}

@KevPantelakis I remember that someone else already had a similar finding with the certs in another context. I don't understand why this fixes the issue but the wiki is updated now.


Dropping a BufferedUarte after writing to it hangs.

In the following example "after write" is printed but "after drop" is never reached.
All the read methods also block forever but while that could be an issue on my end, blocking forever on drop seems very unexpected so I raised this issue.
#[embassy::main]
async fn main(_spawner: Spawner) {
    let mut p = unsafe { Peripherals::steal() };
    let mut irq = interrupt::take!(UARTE0_UART0);

    loop {
        let mut tx_buffer = [0u8; 4096];
        let mut rx_buffer = [0u8; 4096];
        {
            let mut config = uarte::Config::default();
            config.parity = uarte::Parity::EXCLUDED;
            config.baudrate = uarte::Baudrate::BAUD115200;

            let uart = unsafe {
                BufferedUarte::new(
                    &mut p.UARTE0,
                    &mut p.TIMER0,
                    &mut p.PPI_CH0,
                    &mut p.PPI_CH1,
                    &mut irq,
                    &mut p.P1_05,
                    &mut p.P1_04,
                    &mut p.P1_07,
                    &mut p.P1_06,
                    config,
                    &mut rx_buffer,
                    &mut tx_buffer,
                )
            };
            info!("uart initialized!");
            pin_mut!(uart);
            Timer::after(Duration::from_millis(1000)).await;
            info!("before write");
            uart.write_all(b"AT\r\n").await.unwrap();
            info!("after write");
        }
        info!("after drop");
    }
}

This is kinda "known", but it should be fixed yup. UARTE disabling is super tricky.
https://github.com/embassy-rs/embassy/blob/master/embassy-nrf/src/buffered_uarte.rs#L271


Add option to remove notifications

Thanks for this amazing app, me and one of my friend recently discovered this app in f-droid. It is working exactly as expected.
There is only one issue, we'd like to disable notifications completely. I hope you can add this feature!
Best regards.

Sorry, but I no longer support this app


Got HTTP ERROR 431 when Enable AAD Auth for Azure Web App

The first time, I've followed this guideline and bypass the Auth AAD step. It's worked.
But when I on the Auth AAD, It's not worked and got the issue (see image)
When I off the Auth Azure AD, It's worked again.

Hi @huyenvv90 sorry for the issues you're encountering. Seems like AAD Auth is causing issues. Is your use case being able to access Spektate publicly but with authorization?
@samiyaakhtar how difficult would it be to set up an identity provider in Spektate?
Given an AAD application client id and password we could authenticate. The set up could be as follows:

Configure Spektate with AAD Identity provider credentials for a tenant
Run Spektate in your Kubernetes cluster
Setup an Azure public IP address
Setup an ingress in your Kubernetes cluster using the public IP address (Your can configure such that only Azure Front Door as access)
Setup something like Azure Front Door to route to your backend (exposed public IP address)

This way folks can access Spektate security with authorization using Kubernetes to run the workload.

yes, I can access Spektate publicly. But when I setup AAD Auth, it's returned 431 error.