text:
Management commands are not shipped in package

Describe the bug
Installed Lotus into a project then tried to use command "lotus_demo" to add some demo data and Django failed  to find it:
Unknown command: 'lotus_demo'
Type 'manage.py help' for usage.

Environment
Describe your environment:

Plateform: Linux distribution
Python version: 3.8
Django version: 4.0

To Reproduce

Install lotus into a project
Once properly installed, try to use command "lotus_demo"
Django fails to find this command although Lotus is working and correctly installed;

Expected behavior
I would expect to be able to use the command.
When digging to find a reason, i found that the management directory is unexpectedly missing from build package. I installed Lotus 0.5.0 and lookup into the package from the same version as it is available from Pypi.
That's weird since this command exist since before the 0.5.0.

May try to debug with 'setup.py sdist', also the command would need to be ping tested to avoid this kind of issue.

Sadly this command can not be easily tested since it does not have any required argument or a dry-run mode, so if we execute it, this will run creations of many objects and take some minutes to finish.

repo: emencia/django-blog-lotus


text:
JOSS Review: Functionality, documentation

JOSS Review issue
General documentation
I very much appreciate the detailled introduction and explanations regarding the subtleties in running in-silico vs. in-vitro or in-vivo phylogenetic tracking.
Usage example
That being said, I'm missing similar in-depth usage instructions at a more concrete level than what is
provided in the docs. The usage example does not go beyond showing how to instantiate the Systematics class. What can I do with the class from there on? I tried adding an organism, but needed to mock up an Organism class first. Unfortunately, I'm left
entirely on my own with that task. Would be helpful to have some minimum requirements for such an object or even better a template (abstract base class).
Writing an Organism class
Here's my attempt:
from phylotrackpy import systematics

syst = systematics.Systematics(lambda org: org.genotype)

class Organism():
    genotype = "ACTG"

org0 = Organism()

org0.genotype

syst.add_org(org0)

This code lived in a jupyter notebook, executing the last line of code crashed the kernel.
Coding style
I would recommend not to use sys for a local variable name as it obscures the python native library of the same name (which many python codes import)
Usage example recommendation
For a proper usage example I would expect to be instructed how to build a phylogeny from scratch and how to analyse it. You could also provide the data for below figure (from the README) and instruct the user how to reproduce it.

API documentation
Please complete the API documentation and, if done, remove the note "Partially under construction". Probably related to #13 and #22

JOSS Review issue
I am also reviewing this for JOSS, and one of my requests was going to be a usage example - so I thought I would just note here that I concur, this would be a very valuable addition!

Thank you for these very helpful comments! It is so helpful to have an external perspective on where stuff like documentation could be clearer and I really appreciate it (even if though it took me forever to get it fixed!).
I think that we've now addressed all of these points in the documentation. Just to call out a few particularly important components:

Example usage is here: https://phylotrackpy.readthedocs.io/en/latest/example_usage.html
Your organism example actually should have worked. I have fixed the underlying bug, added a test enforcing that it works, and attempted to further clarify the documentation

I'm going to close this (finally!) for now, but feel free to reopen it if you think there's anything we didn't address satisfactorily

source: gharchive/issue

authors: CFGrote RussellGarwood emilydolson

repo: emilydolson/phylotrackpy

license: MIT

license_type: permissive

license_source: github-api


text:
Publish works on Codepen.io

Publish work on codepen.io

art-template published on codepen.

repo: eminaltan/art-template


text:
BUG!BUG! tls-context found no validation certificate in secret client-ca-cert in namespace emi

Symptom
I deployed a demo HTTPS service after applying listner, host, tls-context, mapping and deployment.yaml stuff, all in namespace emi, but I failed to connect to it via curl -v https://<demo.com> with this error:
...
SSL routines:ssl3_get_record:wrong version number

checking pod's log, it shows:
error tls-context.emi.1 TLSContext tls-context found no validation certificate in secret client-cacert in namespace emi

Reproduce
(1)
Freshly install Emissary-ingress via Official tutoral,
(2)
I created two secrets in namespace emi, one for TLS termination (emissary.key, emissary.crt), the other for client's CA cert. all certs are issued using a common root CA cert.
k create -n emi secret generic client-ca-cert --from-file=/usr/local/share/ca-certificates/ca.crt
k create -n emi secret tls emissary-cert --key=emissary.key --cert=emissary.crt

(3)
Simple apply the TLSContext as instructed with this file tls-context.yaml:
apiVersion: getambassador.io/v3alpha1
kind: TLSContext
metadata:
  name: tls-context
  namespace: emi
spec:
  hosts: [ "demo.emissary.io" ]
  secret: emissary-cert
  alpn_protocols: h2
  ca_secret: client-ca-cert.emi
  cert_required: true
  secret_namespacing: true

(4) check pod's logs
k logs emissary-ingress-dffc6b988-4t9cz -n emissary

log results
2022-01-01 07:11:02 diagd 2.1.0 [P23TAEW] ERROR: Secret client-ca-cert.emi unknown
2022-01-01 07:11:02 diagd 2.1.0 [P23TAEW] INFO: tls-context.emi.1: <RichStatus BAD error='TLSContext tls-context found no validation certificate in secret client-ca-cert in namespace emi' hostname='emissary-ingress-dffc6b988-4t9cz' version='2.1.0'>
2022-01-01 07:11:02 diagd 2.1.0 [P23TAEW] INFO: EnvoyConfig: Generating V3
2022-01-01 07:11:02 diagd 2.1.0 [P23TAEW] INFO: V3Listener: ==== GENERATED <V3Listener HTTP listener on 0.0.0.0:8080 [XFP]>
2022-01-01 07:11:02 diagd 2.1.0 [P23TAEW] INFO: configuration updated (incremental) from snapshot snapshot (S23 L1 G4 C2)
2022-01-01 07:11:02 diagd 2.1.0 [P23TAEW] INFO: error tls-context.emi.1 TLSContext tls-context found no validation certificate in secret client-ca-cert in namespace emi
time="2022-01-01 07:11:02.3964" level=info msg="Loaded file /ambassador/envoy/envoy.json" func=github.com/datawire/ambassador/v2/cmd/ambex.Decode file="/go/cmd/ambex/main.go:279" CMD=entrypoint PID=1 THREAD=/ambex
time="2022-01-01 07:11:02.3971" level=info msg="Saved snapshot v16" func=github.com/datawire/ambassador/v2/cmd/ambex.csDump file="/go/cmd/ambex/main.go:369" CMD=entrypoint PID=1 THREAD=/ambex
time="2022-01-01 07:11:02.3976" level=info msg="Pushing snapshot v16" func=github.com/datawire/ambassador/v2/cmd/ambex.updaterWithTicker file="/go/cmd/ambex/ratelimit.go:159" CMD=entrypoint PID=1 THREAD=/ambex
...

Note:
This is a clean installation of Emissary-Ingress, and it simply can not read out the secret? the sure things here are secrets and namespaces are all correct, no clue what could be the problem.

We don't see anything wrong here but perhaps worth noting that Ambassador doesn’t detect a change done the paths defined in cert_chain_file and/or private_key_file and reload the TLSContext cert.  There's a difference in reloading mechanisms between secret-based vs file-based certs.  This is a new cert?
There were a couple bugs with 2.1 - have you tried upgrading to the latest version?

If these are Kubernetes secrets rather than file-based certs and the issue persists on Emissary-ingress 2.x or 3.x please reopen.

repo: emissary-ingress/emissary


text:
Patch breaks wheel support

So I copy over the patched exe, DLL and ini, Launch the game and my Thrustmaster T500RS wheel no longer works. When I go into the controller menu, it thinks the wheel is a keyboard and lists 8 or so keys. If I switch to the keyboard, it’s lists all the x/y axis accelerator, beak options as if it thinks it’s a wheel. Altering any of them will not allow me to assign any wheel inputs. Hope you can fix this.

Could you try changing ControllerHotPlug in the INI to false? Maybe that's causing wheel not to get registered properly.
It might also be worth setting VibrationMode = 0 & ImpulseVibrationMode = 0
PreventDESTSaveCorruption does also interact with the binding menu, maybe PreventDESTSaveCorruption = false could have some effect.

Thanks for the quick feedback! Did the job. Just altered the vibration options to 0 and the ControllerHotPlug to false. Nice one! Keep up the good work!

Thanks for the quick feedback! Did the job. Just altered the vibration options to 0 and the ControllerHotPlug to false. Nice one! Keep up the good work!

Hey @CodingNutz, do you have FXT mod installing alongside Tweaks or is it a fresh install?

Hi, it was a fresh install with Tweaks.However, after poking around the internet, I switched over the FXT after I found out it fixes the massive dead zone on the wheel. Makes the game much more playable. I know it’s deprecated, and your tweaks are newer, but I couldn’t play the game with that quarter turn dead zone. Obviously I’d much prefer to use something newer that’s actively worked on. Could you maybe add some sort of fix for the wheel dead zone??Sent from my iPadOn 8 Jul 2024, at 10:07, chanunnaki @.***> wrote:
Hey @CodingNutz, do you have FXT mod installing alongside Tweaks or is it a fresh install?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

I see... I just set up my wheel yesterday, but only tried it with the Lindburgh/TeknoParrot version because I didn't want to futz around with FXT again and also Tweaks has no mention of wheel support at all, so I wasn't sure what the situation was regarding wheels.
Perhaps you could open another issue @CodingNutz regarding the dead zone!

authors: CodingNutz chanunnaki emoose


text:
too many " Session '28db828a7b3abfed5ec' is duplicated" logs

[error] Session '28db828a7b3abfed5ec' is duplicated:.......
[error] Shutdown for duplicate clientid: ec4d7319f2ffef931d.....

lager:warning/2. Commit: 5117d88b7a876de3c03e4ae63dd8ca9b81550300

repo: emqtt/emqttd

license_source: bigquery


text:
Init confi from Supabase

Fix: #37

IMPORTANT: Please do not create a Pull Request without creating an issue first.

Any change needs to be discussed before proceeding. Failure to do so may result in the rejection of the pull request.

🗓 Changes

Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[X] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[X] This change requires a documentation update

Please provide enough information so that others can review your pull request:

🧬 Details

Explain the details for making this change. What existing problem does the pull request solve?

Adds Supabase
Uses Supabase for configuration

TODO:

Migrate remaining stuff (guilds, plugins..) to Supabase from Mongodb

Checkboxes:

[X] I ran npm run lint and there were no errors
[X] I ran npm run format and there were no errors

Redone in https://github.com/en3sis/hans/pull/44

source: gharchive/pull-request


text:
Total loss trained with 4 channels png file falls to NaN. Anyone has idea?

I concatenate a mask image to a normal RGB picture making .jpg file become .png file with alpha channel.
And I do make sure the 4 channels image loaded properly. But the total loss is always nan while the rpn_cls rpn_box loss_cls and loss_box is an ordinary float as usual.
Anyone has idea about this problem? Thanks~

PS: I don't know much about the channels processing in training, so maybe I left some problem need to fix in training process.

repo: endernewton/tf-faster-rcnn

license: mit


text:
Please fix usage example

could you please add require 'vendor/autoload.php'; to your example.   Without it, it will not work.

Hi @stccorp I try to keep code fragments concise. However I think you have a point that the readme could give some more information about autoloading classes so I added a note about using the autoloader in the installation section and removed the <?php tag to make clearer that the example is just a code fragment and not necessarily a complete working application.
Thank you for your input.

authors: endroid stccorp

repo: endroid/QrCode


text:
Output is formatted with language syntax highlighting

If I specify the syntax with the opening code fence, the bot returns its output with the same syntax highlighting. Here is a simple example:

While I suppose this might be useful if I was writing Python code that generates more Python code, most of the time this isn't the case, and formatting the result as plaintext makes more sense.

Fair point - do you want to fix it yourself and open a PR?

authors: BeauGieskens brtwrst

repo: engineer-man/piston-bot


text:
404 on page refresh / direct link

Hi and thanks for creating this - we use it a lot at our office :)
For the last 1-2 weeks we've experienced a 404 issue if you use a direct link to a league or if you refresh the page.
To reproduce:

Go to https://officeleague.rocks/app/leagues
Click on one of your leagues, e.g. https://officeleague.rocks/app/leagues/geodata
Refresh the page (F5) and you get a white 404 error page with grey text; "D'oh! 404 - Not Found"

The same thing occurs if you use a direct link to a league (like the one in step 2 above), or to the players page, e.g. https://officeleague.rocks/app/leagues/enonic foos/players
Any chance you could take a look at this if you are able to reproduce it?

Thanks for reporting this. 👍
It is really helpful that you reported the specific links that don't work.
It should not be a lot of work to add the links to those pages.
If you find any other pages that do not work with direct links please add them in this issue.

Thanks @poi33. Looks to be everything after the league name so:
https://officeleague.rocks/app/leagues/geodata
https://officeleague.rocks/app/leagues/geodata/players
https://officeleague.rocks/app/leagues/geodata/teams
https://officeleague.rocks/app/leagues/geodata/games

@eithe this is fixed an live now. If you find any more issues with 404 pages just comment on this issue again

Great that you are on this @poi33 :) I'm still getting 404 for the links above, but I'll wait an hour or so and try again :)

https://officeleague.rocks/app/leagues/geodata should be available and no 404.
The other links above are invalid.
Team links look liek this:
https://officeleague.rocks/app/teams/eido og anders
or
https://officeleague.rocks/app/teams/different pigeons
They follow the structure:
app/teams/{name}
And games:
https://officeleague.rocks/app/games/a063d572-cf15-4069-8bc2-8d2c303b11a5
app/games/{gameid}

That's correct; https://officeleague.rocks/app/leagues/geodata works now, but it would be great that the direct link to the list of players also worked if possible (we have that on a display in our office :))

Seems you know the system links better then i do 😅
I'll add the full page overview links to the system.

repo: enonic/app-office-league


text:
Broken Enum in Metabase 0.40.3.1

In Metabase 0.38.2 all was working excellent. Upgrading has broken display Enum. Other types works.
Driver version: 0.7.5
Full trace:
[7436e1b1-ee71-43ef-a33d-3514e7e96085] 2021-08-29T21:33:38+03:00 ERROR metabase.sync.analyze.query-results Error generating insights for column: {:name ua_type, :base_type :type/Enum}
clojure.lang.ExceptionInfo: Output of col->ResultColumnMetadata does not match schema:
	   {:base_type (not ("Valid field data type (keyword or string)" :type/Enum))}
 {:type :schema.core/error, :schema {:name java.lang.String, #schema.core.OptionalKey{:k :unit} (maybe (constrained (named (cond-pre Keyword Str) "Keyword or string") "Valid field datetime unit keyword or string")), #schema.core.OptionalKey{:k :id} (maybe (constrained Int "Integer greater than zero")), #schema.core.OptionalKey{:k :semantic_type} (maybe (pred "Valid field semantic or relation type (keyword or string)")), #schema.core.OptionalKey{:k :description} (maybe (constrained Str "Non-blank string")), Keyword Any, #schema.core.OptionalKey{:k :field_ref} (cond-pre (conditional clojure.core$partial/fn--5839 [(one (eq :aggregation) :aggregation) (one Int "aggregation-clause-index")] clojure.core$constantly/fn--5672 (recursive (var metabase.mbql.schema/Field*))) (pred "Field or aggregation reference as it comes in to the API")), #schema.core.OptionalKey{:k :fingerprint} (maybe {(optional-key :global) {(optional-key :distinct-count) Int, (optional-key :nil%) (maybe (constrained Num "Valid percentage between (inclusive) 0 and 1.")), Any Any}, (optional-key :type) (constrained {(optional-key :type/Number) {(optional-key :min) (maybe Num), (optional-key :max) (maybe Num), (optional-key :avg) (maybe Num), (optional-key :q1) (maybe Num), (optional-key :q3) (maybe Num), (optional-key :sd) (maybe Num), Any Any}, (optional-key :type/Text) {(optional-key :percent-json) (maybe (constrained Num "Valid percentage between (inclusive) 0 and 1.")), (optional-key :percent-url) (maybe (constrained Num "Valid percentage between (inclusive) 0 and 1.")), (optional-key :percent-email) (maybe (constrained Num "Valid percentage between (inclusive) 0 and 1.")), (optional-key :percent-state) (maybe (constrained Num "Valid percentage between (inclusive) 0 and 1.")), (optional-key :average-length) (maybe Num), Any Any}, (optional-key :type/DateTime) {(optional-key :earliest) (maybe Str), (optional-key :latest) (maybe Str), Any Any}, Any Any} "Type-specific fingerprint with exactly one key"), (optional-key :experimental) {Any Any}, Any Any}), :display_name java.lang.String, :base_type (pred "Valid field data type (keyword or string)")}, :value {:base_type :type/Enum, :display_name "ua_type", :name "ua_type"}, :error {:base_type (not ("Valid field data type (keyword or string)" :type/Enum))}}
	at metabase.sync.analyze.query_results$fn__49868$col__GT_ResultColumnMetadata__49873.invoke(query_results.clj:67)
	at metabase.sync.analyze.query_results$insights_rf$iter__49888__49892$fn__49893$fn__49894$fn__49895.invoke(query_results.clj:86)
	at metabase.sync.analyze.query_results$insights_rf$iter__49888__49892$fn__49893$fn__49894.invoke(query_results.clj:85)
	at metabase.sync.analyze.query_results$insights_rf$iter__49888__49892$fn__49893.invoke(query_results.clj:84)
	at clojure.lang.LazySeq.sval(LazySeq.java:42)
	at clojure.lang.LazySeq.seq(LazySeq.java:51)
	at clojure.lang.RT.seq(RT.java:535)
	at clojure.core$seq__5402.invokeStatic(core.clj:137)
	at clojure.core$seq__5402.invoke(core.clj:137)
	at metabase.sync.analyze.query_results$insights_rf$iter__49909__49913$fn__49914.invoke(query_results.clj:92)
	at clojure.lang.LazySeq.sval(LazySeq.java:42)
	at clojure.lang.LazySeq.seq(LazySeq.java:51)
	at clojure.lang.RT.seq(RT.java:535)
	at clojure.core$seq__5402.invokeStatic(core.clj:137)
	at clojure.core$apply.invokeStatic(core.clj:660)
	at clojure.core$apply.invoke(core.clj:660)
	at metabase.sync.analyze.query_results$insights_rf.invokeStatic(query_results.clj:92)
	at metabase.sync.analyze.query_results$insights_rf.invoke(query_results.clj:79)
	at metabase.query_processor.middleware.results_metadata$insights_xform.invokeStatic(results_metadata.clj:127)
	at metabase.query_processor.middleware.results_metadata$insights_xform.invoke(results_metadata.clj:124)
	at metabase.query_processor.middleware.results_metadata$record_and_return_metadata_BANG_$fn__49967$rff_SINGLEQUOTE___49970.invoke(results_metadata.clj:146)
	at metabase.query_processor.middleware.add_rows_truncated$add_rows_truncated$fn__45181$fn__45182.invoke(add_rows_truncated.clj:37)
	at metabase.query_processor.middleware.splice_params_in_response$splice_params_in_response$fn__49982$fn__49983.invoke(splice_params_in_response.clj:34)
	at metabase.query_processor.middleware.add_timezone_info$add_timezone_info$fn__45335$fn__45336.invoke(add_timezone_info.clj:17)
	at metabase.query_processor.middleware.format_rows$format_rows$fn__47833$fn__47836.invoke(format_rows.clj:77)
	at metabase.query_processor.middleware.annotate$add_column_info$fn__41591$fn__41593.invoke(annotate.clj:615)
	at metabase.query_processor.middleware.limit$limit$fn__47888$fn__47889.invoke(limit.clj:40)
	at metabase.query_processor.middleware.mbql_to_native$mbql__GT_native$fn__47902$fn__47905.invoke(mbql_to_native.clj:30)
	at metabase.query_processor.context.default$default_reducef.invokeStatic(default.clj:55)
	at metabase.query_processor.context.default$default_reducef.invoke(default.clj:48)
	at metabase.query_processor.context$reducef.invokeStatic(context.clj:69)
	at metabase.query_processor.context$reducef.invoke(context.clj:62)
	at metabase.query_processor.context.default$default_runf$respond_STAR___37445.invoke(default.clj:69)
	at metabase.driver.sql_jdbc.execute$execute_reducible_query.invokeStatic(execute.clj:485)
	at metabase.driver.sql_jdbc.execute$execute_reducible_query.invoke(execute.clj:463)
	at metabase.driver.sql_jdbc.execute$execute_reducible_query.invokeStatic(execute.clj:472)
	at metabase.driver.sql_jdbc.execute$execute_reducible_query.invoke(execute.clj:463)
	at metabase.driver.sql_jdbc$fn__82288.invokeStatic(sql_jdbc.clj:54)
	at metabase.driver.sql_jdbc$fn__82288.invoke(sql_jdbc.clj:52)
	at clojure.lang.MultiFn.invoke(MultiFn.java:244)
	at metabase.query_processor.context$executef.invokeStatic(context.clj:59)
	at metabase.query_processor.context$executef.invoke(context.clj:48)
	at metabase.query_processor.context.default$default_runf.invokeStatic(default.clj:68)
	at metabase.query_processor.context.default$default_runf.invoke(default.clj:66)
	at metabase.query_processor.context$runf.invokeStatic(context.clj:45)
	at metabase.query_processor.context$runf.invoke(context.clj:39)
	at metabase.query_processor.reducible$pivot.invokeStatic(reducible.clj:34)
	at metabase.query_processor.reducible$pivot.invoke(reducible.clj:31)
	at metabase.query_processor.middleware.mbql_to_native$mbql__GT_native$fn__47902.invoke(mbql_to_native.clj:25)
	at metabase.query_processor.middleware.check_features$check_features$fn__47016.invoke(check_features.clj:39)
	at metabase.query_processor.middleware.limit$limit$fn__47888.invoke(limit.clj:37)
	at metabase.query_processor.middleware.cache$maybe_return_cached_results$fn__46468.invoke(cache.clj:204)
	at metabase.query_processor.middleware.optimize_temporal_filters$optimize_temporal_filters$fn__48148.invoke(optimize_temporal_filters.clj:204)
	at metabase.query_processor.middleware.validate_temporal_bucketing$validate_temporal_bucketing$fn__50080.invoke(validate_temporal_bucketing.clj:50)
	at metabase.query_processor.middleware.auto_parse_filter_values$auto_parse_filter_values$fn__45587.invoke(auto_parse_filter_values.clj:43)
	at metabase.query_processor.middleware.wrap_value_literals$wrap_value_literals$fn__41716.invoke(wrap_value_literals.clj:161)
	at metabase.query_processor.middleware.annotate$add_column_info$fn__41591.invoke(annotate.clj:608)
	at metabase.query_processor.middleware.permissions$check_query_permissions$fn__46888.invoke(permissions.clj:81)
	at metabase.query_processor.middleware.pre_alias_aggregations$pre_alias_aggregations$fn__49009.invoke(pre_alias_aggregations.clj:40)
	at metabase.query_processor.middleware.cumulative_aggregations$handle_cumulative_aggregations$fn__47089.invoke(cumulative_aggregations.clj:60)
	at metabase.query_processor.middleware.resolve_joined_fields$resolve_joined_fields$fn__49306.invoke(resolve_joined_fields.clj:102)
	at metabase.query_processor.middleware.resolve_joins$resolve_joins$fn__49619.invoke(resolve_joins.clj:171)
	at metabase.query_processor.middleware.add_implicit_joins$add_implicit_joins$fn__45163.invoke(add_implicit_joins.clj:190)
	at metabase.query_processor.middleware.large_int_id$convert_id_to_string$fn__47852.invoke(large_int_id.clj:59)
	at metabase.query_processor.middleware.format_rows$format_rows$fn__47833.invoke(format_rows.clj:74)
	at metabase.query_processor.middleware.add_default_temporal_unit$add_default_temporal_unit$fn__44457.invoke(add_default_temporal_unit.clj:23)
	at metabase.query_processor.middleware.desugar$desugar$fn__47155.invoke(desugar.clj:21)
	at metabase.query_processor.middleware.binning$update_binning_strategy$fn__45974.invoke(binning.clj:229)
	at metabase.query_processor.middleware.resolve_fields$resolve_fields$fn__46691.invoke(resolve_fields.clj:34)
	at metabase.query_processor.middleware.add_dimension_projections$add_remapping$fn__44812.invoke(add_dimension_projections.clj:312)
	at metabase.query_processor.middleware.add_implicit_clauses$add_implicit_clauses$fn__45041.invoke(add_implicit_clauses.clj:147)
	at metabase.query_processor.middleware.upgrade_field_literals$upgrade_field_literals$fn__50029.invoke(upgrade_field_literals.clj:40)
	at metabase.query_processor.middleware.add_source_metadata$add_source_metadata_for_source_queries$fn__45326.invoke(add_source_metadata.clj:123)
	at metabase.query_processor.middleware.reconcile_breakout_and_order_by_bucketing$reconcile_breakout_and_order_by_bucketing$fn__49181.invoke(reconcile_breakout_and_order_by_bucketing.clj:100)
	at metabase.query_processor.middleware.auto_bucket_datetimes$auto_bucket_datetimes$fn__45534.invoke(auto_bucket_datetimes.clj:147)
	at metabase.query_processor.middleware.resolve_source_table$resolve_source_tables$fn__46738.invoke(resolve_source_table.clj:45)
	at metabase.query_processor.middleware.parameters$substitute_parameters$fn__48991.invoke(parameters.clj:111)
	at metabase.query_processor.middleware.resolve_referenced$resolve_referenced_card_resources$fn__46790.invoke(resolve_referenced.clj:79)
	at metabase.query_processor.middleware.expand_macros$expand_macros$fn__47539.invoke(expand_macros.clj:184)
	at metabase.query_processor.middleware.add_timezone_info$add_timezone_info$fn__45335.invoke(add_timezone_info.clj:15)
	at metabase.query_processor.middleware.splice_params_in_response$splice_params_in_response$fn__49982.invoke(splice_params_in_response.clj:32)
	at metabase.query_processor.middleware.resolve_database_and_driver$resolve_database_and_driver$fn__49192$fn__49196.invoke(resolve_database_and_driver.clj:31)
	at metabase.driver$do_with_driver.invokeStatic(driver.clj:60)
	at metabase.driver$do_with_driver.invoke(driver.clj:56)
	at metabase.query_processor.middleware.resolve_database_and_driver$resolve_database_and_driver$fn__49192.invoke(resolve_database_and_driver.clj:25)
	at metabase.query_processor.middleware.fetch_source_query$resolve_card_id_source_tables$fn__47779.invoke(fetch_source_query.clj:274)
	at metabase.query_processor.middleware.store$initialize_store$fn__49991$fn__49992.invoke(store.clj:11)
	at metabase.query_processor.store$do_with_store.invokeStatic(store.clj:44)
	at metabase.query_processor.store$do_with_store.invoke(store.clj:38)
	at metabase.query_processor.middleware.store$initialize_store$fn__49991.invoke(store.clj:10)
	at metabase.query_processor.middleware.validate$validate_query$fn__50036.invoke(validate.clj:10)
	at metabase.query_processor.middleware.normalize_query$normalize$fn__47915.invoke(normalize_query.clj:22)
	at metabase.query_processor.middleware.add_rows_truncated$add_rows_truncated$fn__45181.invoke(add_rows_truncated.clj:35)
	at metabase.query_processor.middleware.results_metadata$record_and_return_metadata_BANG_$fn__49967.invoke(results_metadata.clj:147)
	at metabase.query_processor.middleware.constraints$add_default_userland_constraints$fn__47032.invoke(constraints.clj:42)
	at metabase.query_processor.middleware.process_userland_query$process_userland_query$fn__49078.invoke(process_userland_query.clj:134)
	at metabase.query_processor.middleware.catch_exceptions$catch_exceptions$fn__46972.invoke(catch_exceptions.clj:173)
	at metabase.query_processor.reducible$async_qp$qp_STAR___38255$thunk__38256.invoke(reducible.clj:103)
	at metabase.query_processor.reducible$async_qp$qp_STAR___38255.invoke(reducible.clj:109)
	at metabase.query_processor.reducible$sync_qp$qp_STAR___38264$fn__38267.invoke(reducible.clj:135)
	at metabase.query_processor.reducible$sync_qp$qp_STAR___38264.invoke(reducible.clj:134)
	at clojure.lang.AFn.applyToHelper(AFn.java:156)
	at clojure.lang.AFn.applyTo(AFn.java:144)
	at clojure.core$apply.invokeStatic(core.clj:667)
	at clojure.core$apply.invoke(core.clj:660)
	at metabase.query_processor$process_userland_query.invokeStatic(query_processor.clj:241)
	at metabase.query_processor$process_userland_query.doInvoke(query_processor.clj:237)
	at clojure.lang.RestFn.invoke(RestFn.java:423)
	at metabase.query_processor$fn__50126$process_query_and_save_execution_BANG___50135$fn__50138.invoke(query_processor.clj:253)
	at metabase.query_processor$fn__50126$process_query_and_save_execution_BANG___50135.invoke(query_processor.clj:245)
	at metabase.query_processor$fn__50170$process_query_and_save_with_max_results_constraints_BANG___50179$fn__50182.invoke(query_processor.clj:265)
	at metabase.query_processor$fn__50170$process_query_and_save_with_max_results_constraints_BANG___50179.invoke(query_processor.clj:258)
	at metabase.api.dataset$run_query_async$fn__56417.invoke(dataset.clj:56)
	at metabase.query_processor.streaming$streaming_response_STAR_$fn__56396$fn__56397.invoke(streaming.clj:72)
	at metabase.query_processor.streaming$streaming_response_STAR_$fn__56396.invoke(streaming.clj:71)
	at metabase.async.streaming_response$do_f_STAR_.invokeStatic(streaming_response.clj:65)
	at metabase.async.streaming_response$do_f_STAR_.invoke(streaming_response.clj:63)
	at metabase.async.streaming_response$do_f_async$fn__16088.invoke(streaming_response.clj:84)
	at clojure.lang.AFn.applyToHelper(AFn.java:152)
	at clojure.lang.AFn.applyTo(AFn.java:144)
	at clojure.core$apply.invokeStatic(core.clj:665)
	at clojure.core$with_bindings_STAR_.invokeStatic(core.clj:1973)
	at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1973)
	at clojure.lang.RestFn.invoke(RestFn.java:425)
	at clojure.lang.AFn.applyToHelper(AFn.java:156)
	at clojure.lang.RestFn.applyTo(RestFn.java:132)
	at clojure.core$apply.invokeStatic(core.clj:669)
	at clojure.core$bound_fn_STAR_$fn__5749.doInvoke(core.clj:2003)
	at clojure.lang.RestFn.invoke(RestFn.java:397)
	at clojure.lang.AFn.run(AFn.java:22)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)
[7436e1b1-ee71-43ef-a33d-3514e7e96085] 2021-08-29T21:33:38+03:00 ERROR metabase.query-processor.middleware.catch-exceptions Error processing query: null
{:database_id 3,
 :started_at #t "2021-08-29T18:33:38.124666Z[GMT]",
 :via
 [{:status :failed,
   :class clojure.lang.ExceptionInfo,
   :error "Error reducing result rows",
   :stacktrace
   ["--> query_processor.context.default$default_reducef$fn__37441.invoke(default.clj:60)"
    "query_processor.context.default$default_reducef.invokeStatic(default.clj:57)"
    "query_processor.context.default$default_reducef.invoke(default.clj:48)"
    "query_processor.context$reducef.invokeStatic(context.clj:69)"
    "query_processor.context$reducef.invoke(context.clj:62)"
    "query_processor.context.default$default_runf$respond_STAR___37445.invoke(default.clj:69)"
    "driver.sql_jdbc.execute$execute_reducible_query.invokeStatic(execute.clj:485)"
    "driver.sql_jdbc.execute$execute_reducible_query.invoke(execute.clj:463)"
    "driver.sql_jdbc.execute$execute_reducible_query.invokeStatic(execute.clj:472)"
    "driver.sql_jdbc.execute$execute_reducible_query.invoke(execute.clj:463)"
    "driver.sql_jdbc$fn__82288.invokeStatic(sql_jdbc.clj:54)"
    "driver.sql_jdbc$fn__82288.invoke(sql_jdbc.clj:52)"
    "query_processor.context$executef.invokeStatic(context.clj:59)"
    "query_processor.context$executef.invoke(context.clj:48)"
    "query_processor.context.default$default_runf.invokeStatic(default.clj:68)"
    "query_processor.context.default$default_runf.invoke(default.clj:66)"
    "query_processor.context$runf.invokeStatic(context.clj:45)"
    "query_processor.context$runf.invoke(context.clj:39)"
    "query_processor.reducible$pivot.invokeStatic(reducible.clj:34)"
    "query_processor.reducible$pivot.invoke(reducible.clj:31)"
    "query_processor.middleware.mbql_to_native$mbql__GT_native$fn__47902.invoke(mbql_to_native.clj:25)"
    "query_processor.middleware.check_features$check_features$fn__47016.invoke(check_features.clj:39)"
    "query_processor.middleware.limit$limit$fn__47888.invoke(limit.clj:37)"
    "query_processor.middleware.cache$maybe_return_cached_results$fn__46468.invoke(cache.clj:204)"
    "query_processor.middleware.optimize_temporal_filters$optimize_temporal_filters$fn__48148.invoke(optimize_temporal_filters.clj:204)"
    "query_processor.middleware.validate_temporal_bucketing$validate_temporal_bucketing$fn__50080.invoke(validate_temporal_bucketing.clj:50)"
    "query_processor.middleware.auto_parse_filter_values$auto_parse_filter_values$fn__45587.invoke(auto_parse_filter_values.clj:43)"
    "query_processor.middleware.wrap_value_literals$wrap_value_literals$fn__41716.invoke(wrap_value_literals.clj:161)"
    "query_processor.middleware.annotate$add_column_info$fn__41591.invoke(annotate.clj:608)"
    "query_processor.middleware.permissions$check_query_permissions$fn__46888.invoke(permissions.clj:81)"
    "query_processor.middleware.pre_alias_aggregations$pre_alias_aggregations$fn__49009.invoke(pre_alias_aggregations.clj:40)"
    "query_processor.middleware.cumulative_aggregations$handle_cumulative_aggregations$fn__47089.invoke(cumulative_aggregations.clj:60)"
    "query_processor.middleware.resolve_joined_fields$resolve_joined_fields$fn__49306.invoke(resolve_joined_fields.clj:102)"
    "query_processor.middleware.resolve_joins$resolve_joins$fn__49619.invoke(resolve_joins.clj:171)"
    "query_processor.middleware.add_implicit_joins$add_implicit_joins$fn__45163.invoke(add_implicit_joins.clj:190)"
    "query_processor.middleware.large_int_id$convert_id_to_string$fn__47852.invoke(large_int_id.clj:59)"
    "query_processor.middleware.format_rows$format_rows$fn__47833.invoke(format_rows.clj:74)"
    "query_processor.middleware.add_default_temporal_unit$add_default_temporal_unit$fn__44457.invoke(add_default_temporal_unit.clj:23)"
    "query_processor.middleware.desugar$desugar$fn__47155.invoke(desugar.clj:21)"
    "query_processor.middleware.binning$update_binning_strategy$fn__45974.invoke(binning.clj:229)"
    "query_processor.middleware.resolve_fields$resolve_fields$fn__46691.invoke(resolve_fields.clj:34)"
    "query_processor.middleware.add_dimension_projections$add_remapping$fn__44812.invoke(add_dimension_projections.clj:312)"
    "query_processor.middleware.add_implicit_clauses$add_implicit_clauses$fn__45041.invoke(add_implicit_clauses.clj:147)"
    "query_processor.middleware.upgrade_field_literals$upgrade_field_literals$fn__50029.invoke(upgrade_field_literals.clj:40)"
    "query_processor.middleware.add_source_metadata$add_source_metadata_for_source_queries$fn__45326.invoke(add_source_metadata.clj:123)"
    "query_processor.middleware.reconcile_breakout_and_order_by_bucketing$reconcile_breakout_and_order_by_bucketing$fn__49181.invoke(reconcile_breakout_and_order_by_bucketing.clj:100)"
    "query_processor.middleware.auto_bucket_datetimes$auto_bucket_datetimes$fn__45534.invoke(auto_bucket_datetimes.clj:147)"
    "query_processor.middleware.resolve_source_table$resolve_source_tables$fn__46738.invoke(resolve_source_table.clj:45)"
    "query_processor.middleware.parameters$substitute_parameters$fn__48991.invoke(parameters.clj:111)"
    "query_processor.middleware.resolve_referenced$resolve_referenced_card_resources$fn__46790.invoke(resolve_referenced.clj:79)"
    "query_processor.middleware.expand_macros$expand_macros$fn__47539.invoke(expand_macros.clj:184)"
    "query_processor.middleware.add_timezone_info$add_timezone_info$fn__45335.invoke(add_timezone_info.clj:15)"
    "query_processor.middleware.splice_params_in_response$splice_params_in_response$fn__49982.invoke(splice_params_in_response.clj:32)"
    "query_processor.middleware.resolve_database_and_driver$resolve_database_and_driver$fn__49192$fn__49196.invoke(resolve_database_and_driver.clj:31)"
    "driver$do_with_driver.invokeStatic(driver.clj:60)"
    "driver$do_with_driver.invoke(driver.clj:56)"
    "query_processor.middleware.resolve_database_and_driver$resolve_database_and_driver$fn__49192.invoke(resolve_database_and_driver.clj:25)"
    "query_processor.middleware.fetch_source_query$resolve_card_id_source_tables$fn__47779.invoke(fetch_source_query.clj:274)"
    "query_processor.middleware.store$initialize_store$fn__49991$fn__49992.invoke(store.clj:11)"
    "query_processor.store$do_with_store.invokeStatic(store.clj:44)"
    "query_processor.store$do_with_store.invoke(store.clj:38)"
    "query_processor.middleware.store$initialize_store$fn__49991.invoke(store.clj:10)"
    "query_processor.middleware.validate$validate_query$fn__50036.invoke(validate.clj:10)"
    "query_processor.middleware.normalize_query$normalize$fn__47915.invoke(normalize_query.clj:22)"
    "query_processor.middleware.add_rows_truncated$add_rows_truncated$fn__45181.invoke(add_rows_truncated.clj:35)"
    "query_processor.middleware.results_metadata$record_and_return_metadata_BANG_$fn__49967.invoke(results_metadata.clj:147)"
    "query_processor.middleware.constraints$add_default_userland_constraints$fn__47032.invoke(constraints.clj:42)"
    "query_processor.middleware.process_userland_query$process_userland_query$fn__49078.invoke(process_userland_query.clj:134)"
    "query_processor.middleware.catch_exceptions$catch_exceptions$fn__46972.invoke(catch_exceptions.clj:173)"
    "query_processor.reducible$async_qp$qp_STAR___38255$thunk__38256.invoke(reducible.clj:103)"
    "query_processor.reducible$async_qp$qp_STAR___38255.invoke(reducible.clj:109)"
    "query_processor.reducible$sync_qp$qp_STAR___38264$fn__38267.invoke(reducible.clj:135)"
    "query_processor.reducible$sync_qp$qp_STAR___38264.invoke(reducible.clj:134)"
    "query_processor$process_userland_query.invokeStatic(query_processor.clj:241)"
    "query_processor$process_userland_query.doInvoke(query_processor.clj:237)"
    "query_processor$fn__50126$process_query_and_save_execution_BANG___50135$fn__50138.invoke(query_processor.clj:253)"
    "query_processor$fn__50126$process_query_and_save_execution_BANG___50135.invoke(query_processor.clj:245)"
    "query_processor$fn__50170$process_query_and_save_with_max_results_constraints_BANG___50179$fn__50182.invoke(query_processor.clj:265)"
    "query_processor$fn__50170$process_query_and_save_with_max_results_constraints_BANG___50179.invoke(query_processor.clj:258)"
    "api.dataset$run_query_async$fn__56417.invoke(dataset.clj:56)"
    "query_processor.streaming$streaming_response_STAR_$fn__56396$fn__56397.invoke(streaming.clj:72)"
    "query_processor.streaming$streaming_response_STAR_$fn__56396.invoke(streaming.clj:71)"
    "async.streaming_response$do_f_STAR_.invokeStatic(streaming_response.clj:65)"
    "async.streaming_response$do_f_STAR_.invoke(streaming_response.clj:63)"
    "async.streaming_response$do_f_async$fn__16088.invoke(streaming_response.clj:84)"],
   :error_type :qp,
   :ex-data {:type :qp}}],
 :error_type :invalid-query,
 :json_query
 {:type "native",
  :native {:query "select ua_type from zoon.stat\nwhere event_date = today()\nlimit 1\n", :template-tags {}},
  :database 3,
  :parameters [],
  :middleware {:js-int-to-string? true, :add-default-userland-constraints? true}},
 :status :failed,
 :class clojure.lang.ExceptionInfo,
 :stacktrace
 ["--> query_processor.middleware.annotate$fn__41515$deduplicate_cols_names__41520.invoke(annotate.clj:529)"
  "query_processor.middleware.annotate$fn__41543$merged_column_info__41548$fn__41552.invoke(annotate.clj:576)"
  "query_processor.middleware.annotate$fn__41543$merged_column_info__41548.invoke(annotate.clj:569)"
  "query_processor.middleware.annotate$add_column_info_xform$combine__41584.invoke(annotate.clj:600)"
  "query_processor.reducible$combine_additional_reducing_fns$fn__38278.invoke(reducible.clj:206)"
  "query_processor.middleware.limit$limit_xform$fn__47885.invoke(limit.clj:21)"
  "query_processor.context.default$default_reducef$fn__37441.invoke(default.clj:58)"
  "query_processor.context.default$default_reducef.invokeStatic(default.clj:57)"
  "query_processor.context.default$default_reducef.invoke(default.clj:48)"
  "query_processor.context$reducef.invokeStatic(context.clj:69)"
  "query_processor.context$reducef.invoke(context.clj:62)"
  "query_processor.context.default$default_runf$respond_STAR___37445.invoke(default.clj:69)"
  "driver.sql_jdbc.execute$execute_reducible_query.invokeStatic(execute.clj:485)"
  "driver.sql_jdbc.execute$execute_reducible_query.invoke(execute.clj:463)"
  "driver.sql_jdbc.execute$execute_reducible_query.invokeStatic(execute.clj:472)"
  "driver.sql_jdbc.execute$execute_reducible_query.invoke(execute.clj:463)"
  "driver.sql_jdbc$fn__82288.invokeStatic(sql_jdbc.clj:54)"
  "driver.sql_jdbc$fn__82288.invoke(sql_jdbc.clj:52)"
  "query_processor.context$executef.invokeStatic(context.clj:59)"
  "query_processor.context$executef.invoke(context.clj:48)"
  "query_processor.context.default$default_runf.invokeStatic(default.clj:68)"
  "query_processor.context.default$default_runf.invoke(default.clj:66)"
  "query_processor.context$runf.invokeStatic(context.clj:45)"
  "query_processor.context$runf.invoke(context.clj:39)"
  "query_processor.reducible$pivot.invokeStatic(reducible.clj:34)"
  "query_processor.reducible$pivot.invoke(reducible.clj:31)"
  "query_processor.middleware.mbql_to_native$mbql__GT_native$fn__47902.invoke(mbql_to_native.clj:25)"
  "query_processor.middleware.check_features$check_features$fn__47016.invoke(check_features.clj:39)"
  "query_processor.middleware.limit$limit$fn__47888.invoke(limit.clj:37)"
  "query_processor.middleware.cache$maybe_return_cached_results$fn__46468.invoke(cache.clj:204)"
  "query_processor.middleware.optimize_temporal_filters$optimize_temporal_filters$fn__48148.invoke(optimize_temporal_filters.clj:204)"
  "query_processor.middleware.validate_temporal_bucketing$validate_temporal_bucketing$fn__50080.invoke(validate_temporal_bucketing.clj:50)"
  "query_processor.middleware.auto_parse_filter_values$auto_parse_filter_values$fn__45587.invoke(auto_parse_filter_values.clj:43)"
  "query_processor.middleware.wrap_value_literals$wrap_value_literals$fn__41716.invoke(wrap_value_literals.clj:161)"
  "query_processor.middleware.annotate$add_column_info$fn__41591.invoke(annotate.clj:608)"
  "query_processor.middleware.permissions$check_query_permissions$fn__46888.invoke(permissions.clj:81)"
  "query_processor.middleware.pre_alias_aggregations$pre_alias_aggregations$fn__49009.invoke(pre_alias_aggregations.clj:40)"
  "query_processor.middleware.cumulative_aggregations$handle_cumulative_aggregations$fn__47089.invoke(cumulative_aggregations.clj:60)"
  "query_processor.middleware.resolve_joined_fields$resolve_joined_fields$fn__49306.invoke(resolve_joined_fields.clj:102)"
  "query_processor.middleware.resolve_joins$resolve_joins$fn__49619.invoke(resolve_joins.clj:171)"
  "query_processor.middleware.add_implicit_joins$add_implicit_joins$fn__45163.invoke(add_implicit_joins.clj:190)"
  "query_processor.middleware.large_int_id$convert_id_to_string$fn__47852.invoke(large_int_id.clj:59)"
  "query_processor.middleware.format_rows$format_rows$fn__47833.invoke(format_rows.clj:74)"
  "query_processor.middleware.add_default_temporal_unit$add_default_temporal_unit$fn__44457.invoke(add_default_temporal_unit.clj:23)"
  "query_processor.middleware.desugar$desugar$fn__47155.invoke(desugar.clj:21)"
  "query_processor.middleware.binning$update_binning_strategy$fn__45974.invoke(binning.clj:229)"
  "query_processor.middleware.resolve_fields$resolve_fields$fn__46691.invoke(resolve_fields.clj:34)"
  "query_processor.middleware.add_dimension_projections$add_remapping$fn__44812.invoke(add_dimension_projections.clj:312)"
  "query_processor.middleware.add_implicit_clauses$add_implicit_clauses$fn__45041.invoke(add_implicit_clauses.clj:147)"
  "query_processor.middleware.upgrade_field_literals$upgrade_field_literals$fn__50029.invoke(upgrade_field_literals.clj:40)"
  "query_processor.middleware.add_source_metadata$add_source_metadata_for_source_queries$fn__45326.invoke(add_source_metadata.clj:123)"
  "query_processor.middleware.reconcile_breakout_and_order_by_bucketing$reconcile_breakout_and_order_by_bucketing$fn__49181.invoke(reconcile_breakout_and_order_by_bucketing.clj:100)"
  "query_processor.middleware.auto_bucket_datetimes$auto_bucket_datetimes$fn__45534.invoke(auto_bucket_datetimes.clj:147)"
  "query_processor.middleware.resolve_source_table$resolve_source_tables$fn__46738.invoke(resolve_source_table.clj:45)"
  "query_processor.middleware.parameters$substitute_parameters$fn__48991.invoke(parameters.clj:111)"
  "query_processor.middleware.resolve_referenced$resolve_referenced_card_resources$fn__46790.invoke(resolve_referenced.clj:79)"
  "query_processor.middleware.expand_macros$expand_macros$fn__47539.invoke(expand_macros.clj:184)"
  "query_processor.middleware.add_timezone_info$add_timezone_info$fn__45335.invoke(add_timezone_info.clj:15)"
  "query_processor.middleware.splice_params_in_response$splice_params_in_response$fn__49982.invoke(splice_params_in_response.clj:32)"
  "query_processor.middleware.resolve_database_and_driver$resolve_database_and_driver$fn__49192$fn__49196.invoke(resolve_database_and_driver.clj:31)"
  "driver$do_with_driver.invokeStatic(driver.clj:60)"
  "driver$do_with_driver.invoke(driver.clj:56)"
  "query_processor.middleware.resolve_database_and_driver$resolve_database_and_driver$fn__49192.invoke(resolve_database_and_driver.clj:25)"
  "query_processor.middleware.fetch_source_query$resolve_card_id_source_tables$fn__47779.invoke(fetch_source_query.clj:274)"
  "query_processor.middleware.store$initialize_store$fn__49991$fn__49992.invoke(store.clj:11)"
  "query_processor.store$do_with_store.invokeStatic(store.clj:44)"
  "query_processor.store$do_with_store.invoke(store.clj:38)"
  "query_processor.middleware.store$initialize_store$fn__49991.invoke(store.clj:10)"
  "query_processor.middleware.validate$validate_query$fn__50036.invoke(validate.clj:10)"
  "query_processor.middleware.normalize_query$normalize$fn__47915.invoke(normalize_query.clj:22)"
  "query_processor.middleware.add_rows_truncated$add_rows_truncated$fn__45181.invoke(add_rows_truncated.clj:35)"
  "query_processor.middleware.results_metadata$record_and_return_metadata_BANG_$fn__49967.invoke(results_metadata.clj:147)"
  "query_processor.middleware.constraints$add_default_userland_constraints$fn__47032.invoke(constraints.clj:42)"
  "query_processor.middleware.process_userland_query$process_userland_query$fn__49078.invoke(process_userland_query.clj:134)"
  "query_processor.middleware.catch_exceptions$catch_exceptions$fn__46972.invoke(catch_exceptions.clj:173)"
  "query_processor.reducible$async_qp$qp_STAR___38255$thunk__38256.invoke(reducible.clj:103)"
  "query_processor.reducible$async_qp$qp_STAR___38255.invoke(reducible.clj:109)"
  "query_processor.reducible$sync_qp$qp_STAR___38264$fn__38267.invoke(reducible.clj:135)"
  "query_processor.reducible$sync_qp$qp_STAR___38264.invoke(reducible.clj:134)"
  "query_processor$process_userland_query.invokeStatic(query_processor.clj:241)"
  "query_processor$process_userland_query.doInvoke(query_processor.clj:237)"
  "query_processor$fn__50126$process_query_and_save_execution_BANG___50135$fn__50138.invoke(query_processor.clj:253)"
  "query_processor$fn__50126$process_query_and_save_execution_BANG___50135.invoke(query_processor.clj:245)"
  "query_processor$fn__50170$process_query_and_save_with_max_results_constraints_BANG___50179$fn__50182.invoke(query_processor.clj:265)"
  "query_processor$fn__50170$process_query_and_save_with_max_results_constraints_BANG___50179.invoke(query_processor.clj:258)"
  "api.dataset$run_query_async$fn__56417.invoke(dataset.clj:56)"
  "query_processor.streaming$streaming_response_STAR_$fn__56396$fn__56397.invoke(streaming.clj:72)"
  "query_processor.streaming$streaming_response_STAR_$fn__56396.invoke(streaming.clj:71)"
  "async.streaming_response$do_f_STAR_.invokeStatic(streaming_response.clj:65)"
  "async.streaming_response$do_f_STAR_.invoke(streaming_response.clj:63)"
  "async.streaming_response$do_f_async$fn__16088.invoke(streaming_response.clj:84)"],
 :context :ad-hoc,
 :error
 "Input to deduplicate-cols-names does not match schema: \n\n\t   [(named [{:base_type (not (\"Valid field type\" :type/Enum)), :field_ref (named [nil nil (named {:base-type (not (\"Valid field type\" :type/Enum))} \"options\")] \"Must be a valid instance of one of these clauses: :expression, :field\")}] cols)]  \n\n",
 :row_count 0,
 :running_time 0,
 :ex-data
 {:type :schema.core/error,
  :value
  [[{:display_name "ua_type",
     :source :native,
     :field_ref [:field "ua_type" {:base-type :type/Enum}],
     :name "ua_type",
     :base_type :type/Enum}]],
  :error
  [(named [{:base_type (not ("Valid field type" :type/Enum)), :field_ref (named [nil nil (named {:base-type (not ("Valid field type" :type/Enum))} "options")] "Must be a valid instance of one of these clauses: :expression, :field")}] cols)]},
 :data {:rows [], :cols []}}

Same problem!
metabase version: v0.41.2
clickhouse driver: Metabase ClickHouse Driver 0.7.5
error:
ERROR analyze.query-results :: ： {:name role, :base_type :type/Enum}
clojure.lang.ExceptionInfo: Output of col->ResultColumnMetadata does not match schema:

the role field using clickhouse Enum8.

Sorry about that. Metabase authors decided to throw an Exception when a type was not "supported". We are now mapping Enum to type/Text, so this issue should not occur anymore. Please try with driver version 0.8.0.

@grkhr can you check if it works now?

Closing it as enums are working now. However, we will consider a more optimal implementation in future releases.

authors: enqueue fangpeng-lingoace grkhr slvrtrn

repo: enqueue/metabase-clickhouse-driver


text:
Notify the user to disable Client-side Translation

Client side Translation (e.g. Chrome translating to Italian) can result in client side errors when generating answers.
Detect such a condition and notify the user to disable the translation service with a persistent warning.
Only sample 2s after the chat app is up with a hook.

repo: enricoros/big-AGI


text:
LocalAI Model Gallery Doesn't Work

Description
Follow instructions to setup LocalAI Model Gallery. Click "Gallery Admin."
Available Models List: (truncated)
[ { "code": "invalid_type", "expected": "string", "received": "undefined", "path": [ 63, "license" ]...
Command Prompt: curl http://localhost:8080/models/available: (truncated)
..."}},"files":[{"filename":"xwin-mlewd-13b-v0.2.Q8_0.gguf","sha256":"","uri":"https://huggingface.co/TheBloke/Xwin-MLewd-13B-v0.2-...
Device and browser
Windows 11 Latest Brave
Screenshots and more
No response
Willingness to Contribute

[ ] 🙋♂ Yes, I would like to contribute a fix.

It works with the official gallery, but not the community one

Closing as a fix has been provided.

authors: enricoros oldmanjk


text:
Don't use shadow DOM as it has been deprecated

Fixes #304

👍

authors: hedefalk mads-hartmann

repo: ensime/ensime-atom


text:
EnDeclaration: manually execute autocmds

Without this change, upon calling EnDeclaration I lose both syntax highlighting and airline coloring in neovim 0.1.1.
AFAICT this happens because autocmds are apparently not executed when using the API, so we have to call them manually.
I have tested this PR with both vim and neovim, and get syntax highlighting after EnDeclaration in both versions.  This might also solve @yazgoo's problems from #124.

LGTM!

Thanks gebner!

authors: gebner vito-c yazgoo

repo: ensime/ensime-vim


text:
Enso stops responding to inputs and no cursor is rendered

Discord username
No response
What type of issue is this?
Permanent – Occurring repeatably
Is this issue blocking you from using Enso?

[X] Yes, I can't use Enso because of this issue.

Is this a regression?

[X] Yes, previous version of Enso did not have this issue.

What issue are you facing?
Enso stops responding to inputs after CB is opened and typing method name is rewritten (typed ie. deli backpsaced it and typed to) as you can see on the video here:
https://github.com/enso-org/enso/assets/108271897/4c6bcb5d-5fac-4575-8eb0-6f27181b3a91
I can repeatedly invoke this error.
Expected behaviour
Enso working after searcher input is edited multiple times
How we can reproduce it?
No response
Screenshots or screencasts
No response
Logs
20230606-073615-891-enso-project-manager.log
Enso Version
2023.6.6 nightly
Browser or standalone distribution
Standalone distribution (local project)
Browser Version or standalone distribution
standalone
Operating System
Windows
Operating System Version
Win11pro 22H2 22621.1555
Hardware you are using
12th Gen Intel(R) Core(TM) i9-12900HK / RTX3060 Laptop / Nvidia Drivers 531.68

Nightly 2023.6.5 log with same problem:
20230606-074935-585-enso-project-manager.log

The issue is that to_uri is being passed a massive string (7.2Mb) and reporting an error message containing this.
The IDE is then trying to render this (assuming it makes it over the lang server protocol) and freezing while it tries to render.
I have amend to_uri to truncate the URI if a syntax error but IDE team should also look at where the IDE is hanging.
cc: @farmaazon

I guess we try to display a 7.2 Mb string in HTML, trusting the engine that error messages are always reasonably small.

I am amending this error message but it completely hangs the IDE at the moment - so might be worth taking just the first 256 characters or similar.

Nightly 2023.6.7 still freezes on to_uri suggestion displayed in CB

@jdunkerley shouldn't the message cut be performed somewhere "higher" than IDE? The messages should be reasonably short, regardless if we display them in IDE or print to console (nobody will gladly read 7.2 Mb bump).
Or have you done it already, and IDE is still freezing?

@jdunkerley bump ^

@4e6 @hubertp check it out what can be added there as James has mentioned

If however, a long panic message gets to the IDE, it will still hang it. We could add something in the language server as well. Given our limited rendering capability on error messages at the moment feels like we should truncate the message.

Yes, we can add a truncation logic on the language server side before sending the error messages

authors: 4e6 farmaazon jdunkerley xvcgreg

repo: enso-org/enso


text:
Upserting a row with UUID as ID results in an error

First of all let me just say THANK YOU to everyone's involved in this project.
I extremely appreciate all of your work.

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯
I use UUIDs (Google's package) as primary keys, for example:
func (Test) Fields() []ent.Field {
	return []ent.Field{
		field.UUID(`id`, uuid.UUID{}).Unique(),
		field.Int8(`count`).Min(0),
	}
}

If I insert new rows, everything works as expected without errors:
err = r.client.Test.
	Create().
	SetID(id).
	SetCount(1).
	Exec(r.context)

But, if I try to upsert rows, even new ones:
err = r.client.Test.
	Create().
	SetID(id).
	SetCount(currentCount + 1).
	OnConflictColumns(test.FieldID).
	UpdateCount().
	Exec(r.context)

I get the following error: interface conversion: driver.Value is string, not uuid.UUID
Expected Behavior 🤔
I expect a new row to be updated if the ID exists or inserted if the ID does not exist, without any error.
Steps to Reproduce 🕹
I think the above code should suffice to reproduce the issue.
Some Notes
I tracked the issue to a method called sqlSave in the generated file test_create.go, to the following lines:
if _spec.ID.Value != nil {
	_node.ID = _spec.ID.Value.(uuid.UUID)
}

I believe the issue is related to the combination of Ent's upsert and Google's UUID Value method.
When just inserting a new row (without OnConflictColumns) the type definition _spec.ID.Type is field.TypeUUID, or [16]byte as you defined it, and the actual type of _spec.ID.Value is uuid.UUID.
But when upserting a row, while the type definition _spec.ID.Type remains the same field.TypeUUID/[16]byte, the actual type of _spec.ID.Value is string.
It looks like the function sqlgraph.CreateNode is doing something to _spec, because before it is called, _spec.ID.Value's type is uuid.UUID, and after it's run the type changes to string.
Your Environment 🌎

Tech
Version

Go
1.17.1

Ent
0.9.1

Database
PostgreSQL

Driver
github.com/jackc/pgx/v4/stdlib

I hope I've been as helpful as possible, let me know if there's anything else I can do.

Thanks for reporting this @726b. I'll give it a look and update you.

Thanks again for reporting this. A patch was created to address this issue (see https://github.com/ent/ent/pull/1987) and should be land tomorrow.

Thank you @a8m for this package, again I extremely appreciate you and everyone else's work here.

Closed with https://github.com/ent/ent/pull/1987
Please update to the latest master version as follows:
go get entgo.io/ent@master

@a8m
I'm using ent v0.10.1, but it seems like this issue still remain when I use custom IDs as ID.
To give an example, I use ULIDs as primary keys.
func (Test) Fields() []ent.Field {
	return []ent.Field{
		field.String("id").
			GoType(ulid.ID("")).
			DefaultFunc(func() ulid.ID { return ulid.New() }),
	}
}

if I try to upsert rows,
err := client.Test.Create().OnConflict(sql.ResolveWithNewValues()).Exec(ctx);

I get the following error: unexpected Test.ID type: string

repo: ent/ent


text:
Signed In Message incorrect styling/coloring

Fix the styling for login notifications

PR Raised: https://github.com/entdec/satis/pull/157

repo: entdec/satis


text:
coverage: integration test for LocalErrorFilter when using gRPC

Description: This test covers the case where the LocalErrorFilter transforms a locally generated response for a gRPC request to an error.
Risk Level: Low
Testing: This commit adds coverage.
Signed-off-by: Mike Schore mike.schore@gmail.com

We don't currently have support for this level of integration testing on Kotlin. It is something that I'd like for us to add, but there are a few missing pieces we need first--most notably a non-Android build target.

thanks @junr03!

repo: envoyproxy/envoy-mobile


text:
Stats filtering inclusion list is not working for server level metrics

We have the following configuration in envoy
    stats_config:
      stats_matcher:
        inclusion_list:
          patterns:
          - suffix: upstream_cx_total
          - exact: envoy_server_state

In this case, the metrics with suffix upstream_cx_total is emitted properly, but the metric envoy_server_state is never emitted. Please check if this a bug, we have a large config and metrics is slowing envoy down, hence wanted to include only the required metrics which is a combination of cluster and server level metrics.

@shyamradhakrishnan I believe what you want is exact: server.state, the stats matcher is based on their canonical name, names in Prometheus exporter are normalized to Prometheus naming convention (with envoy prefix).

Thanks @lizan , that was the issue.

authors: lizan shyamradhakrishnan

repo: envoyproxy/envoy


text:
Move postgres_proxy filter to mainline extensions

We would like to use the postgres filter support provided by Envoy in production.
While the feature works nicely with standalone envoy, we are having trouble using the same via Istio. (see https://github.com/istio/istio/issues/42380)
For the EnvoyFilter to be supported in Istio, the filter has to be promoted to mainline extensions in Envoy.
Would like to know what does it take for promoting the same.
I think postgres has been in contrib for quite sometime, (https://github.com/envoyproxy/envoy/commits/0ce6cf5fc3b54185b068ac0b6ec2dd5e461fc3cb/api/contrib/envoy/extensions/filters/network/postgres_proxy) , hence would like to know the opinion about moving the same to mainline.

cc @cpakulski

I do not know what are exact criteria for accepting an extension to be part of the core code. postgres filter's security posture requires trusted upstream and downstream. Unit and integration tests are quite solid, but fuzz testing is missing. I would be happy to work on improving security posture (if required) and actual move of the code, but need to know the acceptance requirements.

@mattklein123 @ggreenway any suggestions on this? How do we get maintainers to sponsor?

@kfaseela Istio explicitly put postgres behind opt-in because there was a lack of interest from the maintainer of both projects to support postgres as a first-class end-user feature of the service mesh. If Istio can commit to delivering postgres, I think it's easier to find interest among Envoy maintainer for the code that would be widely used.

@kyessenov : many of the users of Istio do have customers who need postgres support. If envoy moves this out of contrib mode, it will be automatically pulled in by istio, helping us to use it via EnvoyFilter. Currently there is no plan to support via standard Istio APIs, but without being available as an EnvoyFilter atleast, Istio cannot make use of this feature to decide whether we would eventually want to mainstream it. So why not move out of contrib mode to help some of the Istio users like us?

@kfaseela I don't think we have a blockage in Istio here: we can modify Istio OSS to pull from contrib without issues. The reason for contrib is what I described: we need commitment for end-user adoption, with appropriate resources allocated. If it stays as contrib/EnvoyFilter combination, vendors are unlikely to provide support in this area (spoken while wearing my Googler hat).

@kfaseela I don't think we have a blockage in Istio here: we can modify Istio OSS to pull from contrib without issues. The reason for contrib is what I described: we need commitment for end-user adoption, with appropriate resources allocated. If it stays as contrib/EnvoyFilter combination, vendors are unlikely to provide support in this area (spoken while wearing my Googler hat).

@kyessenov The current issue was raised here as a follow up to @ramaraochavali 's comment on https://github.com/istio/istio/issues/42380#issuecomment-1344368073 . So are you saying the EnvoyFilter should work with vanila Istio without the need to move this out of contrib?

I am referring to the fact that Istio can include Envoy contrib extensions into istio/proxy. Whether it should or not is a different matter.

Per @kyessenov I would raise this issue with the Istio project. Thank you.

authors: cpakulski kfaseela kyessenov mattklein123


text:
Heathcheck for traffic splitting

Title: Heathcheck for traffic splitting
Description:

We are using the traffic splitting using envoy. We are traffic splitting between the two cluster and it is working fine, however when host is not available in the cluster then envoy still traffic split to that cluster. Was thinking if we can use the heathcheck to make sure when host is not available in the cluster then envoy should not traffic split to that cluster or do we have any feature to make sure traffic split does not goes to cluster when their are no hosts available in that cluster.

[optional Relevant Links:]

Any extra documentation required to understand the issue.

If you have only one host for the shadow requests it is likely going into the panic mode https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/panic_threshold#panic-threshold when it becomes unhealthy and continue to send requests to it.
It would require additional work to disable shadow requests in this situation. I will mark this as a feature request.

authors: someshsumantwilio yanavlasov


text:
util: memcpy of whole structures should have a macro wrapper

Per discussion in https://github.com/envoyproxy/envoy/pull/9306 we should have a check_format check for memcpy, with carve-outs for the buffer-appending case in that PR, and for a macro definition we add for copying blocks in a way that obviously cannot have memory bounds, e.g.:
#define MEMCPY(dst, src)  memcpy(dst, src, sizeof(*(src)))

or maybe
#define MEMCPY(dst, src)  memcpy(dst, src, std::min(sizeof(*(src), sizeof(*(dst))))

or maybe
#define MEMCPY(dst, src)  \
 do { \
    static_assert(sizeof(*(src)) == sizeof(*(dst))); \
    memcpy(dst, src, sizeof(*(src))); \
  } while (false)

The macro is easy enough but there are 56 current violation of this outside of tests. One option is to check in the macro and one or two uses, but whitelist all the existing uses and incrementally remove them.

diff --git a/tools/check_format.py b/tools/check_format.py
index a7bb5daf74..989493f944 100755
--- a/tools/check_format.py
+++ b/tools/check_format.py
@@ -43,6 +43,9 @@ REAL_TIME_WHITELIST = ("./source/common/common/utility.h",
                        "./test/test_common/utility.cc", "./test/test_common/utility.h",
                        "./test/integration/integration.h")

+MEMCPY_WHITELIST = ("./source/common/common/mem_block_builder.h",
+                    "./source/common/common/safe_memcpy.h")
+
 # Files in these paths can use MessageLite::SerializeAsString
 SERIALIZE_AS_STRING_WHITELIST = (
     "./source/common/config/version_converter.cc",
@@ -287,6 +290,10 @@ def whitelistedForRealTime(file_path):
   return file_path in REAL_TIME_WHITELIST

+def whitelistedForMemcpy(file_path):
+  return file_path in MEMCPY_WHITELIST
+
+
 def whitelistedForSerializeAsString(file_path):
   return file_path in SERIALIZE_AS_STRING_WHITELIST

@@ -585,6 +592,8 @@ def checkSourceLine(line, file_path, reportError):
       if comment == -1 or comment > grpc_init_or_shutdown:
         reportError("Don't call grpc_init() or grpc_shutdown() directly, instantiate " +
                     "Grpc::GoogleGrpcContext. See #8282")
+  if not whitelistedForMemcpy(file_path) and not "test/" in file_path and "memcpy(" in line:
+    reportError("Don't call memcpy() directly; use SAFE_MEMCPY or MemBlockBuilder.")

 def checkBuildLine(line, file_path, reportError):

@adisuissa also pointed out that there is an Abseil span-based pattern that works nicely here at https://abseil.io/tips/93

MemBlockBuilder uses absl::Span fwiw

Hi 👋  @jmarantz, I would like to work on this issue.

Sounds good @gria1 -- please give it a go! Happy to review.

Great, thanks! So as to clarify ideas, it is expected the SAFE_MEMCPY macro to be added and changes to the use of memcpy(...) for either this or MemBlockBuilder in the source. Then, a set of tests (in the check_format.py script) must be included for a couple of this changes. Did I missed something? Does the macro ought to be written in its own header file or is it prefered to be under source/common/common/mem_block_builder.h

I think I'd put that new macro in source/common/common/macros.h.

Hi, I am facing some difficulties when trying to compile the project locally using the docker container (with envoyproxy/envoy-build-ubuntu:b480535e8423b5fd7c102fd30c92f4785519e33a as its image). It seems there is an issue with some external dependency (mainly, zlib), so I was wondering whether you have seen this before.
$./ci/run_envoy_docker.sh './ci/do_ci.sh bazel.dev'

(env. output omitted)

INFO: Analyzed target //source/exe:envoy-static (722 packages loaded, 38899 targets configured).
INFO: Found 1 target...
INFO: From CcCmakeMakeRule external/envoy/bazel/foreign_cc/zlib/include [for host]:

ERROR: /build/tmp/_bazel_envoybuild/b570b5ccd0454dc9af9f65ab1833764d/external/envoy/bazel/foreign_cc/BUILD:343:21: Error while validating output TreeArtifact File:[[<execution_root>]bazel-out/host/bin]external/envoy/bazel/foreign_cc/zlib/include : Failed to resolve relative path include/zconf.h inside TreeArtifact /build/tmp/_bazel_envoybuild/b570b5ccd0454dc9af9f65ab1833764d/execroot/envoy/bazel-out/host/bin/external/envoy/bazel/foreign_cc/zlib/include. The associated file is either missing or is an invalid symlink.
ERROR: /build/tmp/_bazel_envoybuild/b570b5ccd0454dc9af9f65ab1833764d/external/envoy/bazel/foreign_cc/BUILD:343:21: TreeArtifact external/envoy/bazel/foreign_cc/copy_zlib/zlib was not created
ERROR: /build/tmp/_bazel_envoybuild/b570b5ccd0454dc9af9f65ab1833764d/external/envoy/bazel/foreign_cc/BUILD:343:21: not all outputs were created or valid
Target //source/exe:envoy-static failed to build
ERROR: /build/tmp/_bazel_envoybuild/b570b5ccd0454dc9af9f65ab1833764d/external/com_github_cncf_udpa/udpa/annotations/BUILD:5:19 not all outputs were created or valid
INFO: Elapsed time: 640.918s, Critical Path: 6.80s
INFO: 90 processes: 82 internal, 8 processwrapper-sandbox.
FAILED: Build did NOT complete successfully

I haven't but I confess I do not use docker. Not sure if that's related.

Anyway, another more relevant question hehe 😅 ,  personally, I am struggling a bit when deciding whether to choose SAFE_MEMCPY or MemBlockBuilder. For instance, would you (@jmarantz) consider the following a valid usage of either of those? And in case it is not, would you you provide a simple example to clear our some ideas?
(Thxs in advanced 👍 )
diff --git a/source/extensions/filters/udp/dns_filter/dns_parser.cc b/source/extensions/filters/udp/dns_filter/dns_parser.cc
index 763424a63..6d6509164 100644
--- a/source/extensions/filters/udp/dns_filter/dns_parser.cc
+++ b/source/extensions/filters/udp/dns_filter/dns_parser.cc
@@ -5,6 +5,8 @@
 #include "common/network/address_impl.h"
 #include "common/network/utility.h"

+#include "common/common/mem_block_builder.h"
+
 #include "extensions/filters/udp/dns_filter/dns_filter_utils.h"

 #include "ares.h"
@@ -171,7 +173,9 @@ bool DnsMessageParser::parseDnsObject(DnsQueryContextPtr& context,
       state = DnsQueryParseState::Flags;
       break;
     case DnsQueryParseState::Flags:
-      ::memcpy(static_cast<void*>(&header_.flags), &data, field_size);
+      MemBlockBuilder<void*> mem_builder(field_size);
+      mem_builder.appendOne(static_cast<void*>(&data));
+      SAFE_MEMCPY(&header_.flags, mem_builder.release());
       state = DnsQueryParseState::Questions;
       break;
     case DnsQueryParseState::Questions:
@@ -741,7 +745,7 @@ void DnsMessageParser::buildResponseBuffer(DnsQueryContextPtr& query_context,
   buffer.writeBEInt<uint16_t>(response_header_.id);

   uint16_t flags;
-  ::memcpy(&flags, static_cast<void*>(&response_header_.flags), sizeof(uint16_t));
+  SAFE_MEMCPY(&flags, static_cast<void*>(&response_header_.flags));
   buffer.writeBEInt<uint16_t>(flags);

   buffer.writeBEInt<uint16_t>(response_header_.questions);

I think SAFE_MEMCPY seems appropriate, if the types match. And in that case we should be able to drop the void* cast. I'm skeptical of the safety of anything that requires the void* cast.
If we need to we should be able to put the void* cast into the SAFE_MEMCPY macro definition, after first having validated that the source/dest sizes are the same.

Is this something that can be accomplished by a template function instead of a macro?

Agreed: I don't know why I didn't suggest that in the first place. We should use a template function rather than a macro for this. I think (other than renames for style) it will otherwise be a drop-in replacement.

Ok, I will try to make the replacement in the PR.

authors: antoniovicente grial1 htuch jmarantz


text:
wasm: enable WAVM's stack unwinding feature

This PR enables WAVM's stack unwind feature, which enhance WASM extension developers debuggability dramatically.
Without WAVM_ENABLE_UNWIND=on, the returned call stack is always empty as you can see here.
The corresponding PR in proxy-wasm-cpp-host is here: https://github.com/proxy-wasm/proxy-wasm-cpp-host/pull/84
The stack trace message is something like this:
[2020-10-28 14:24:10.551][979699][trace][wasm] [source/extensions/common/wasm/wasm_vm.cc:29] Function proxy_on_tick failed:
WAVM message: wavm.reachedUnreachable
wasm backrace:
  1: wasm!helloworld!runtime._panic+7
  2: wasm!helloworld!command-line-arguments.C+2
  3: wasm!helloworld!command-line-arguments.B+0
  4: wasm!helloworld!command-line-arguments.A+0
  5: wasm!helloworld!(*command-line-arguments.helloWorld).OnTick+74
  6: wasm!helloworld!proxy_on_tick+0

Signed-off-by: mathetake takeshi@tetrate.io

cc @lizan @PiotrSikora

@mathetake in the future, you might want to include proxy-wasm-cpp-host update in bazel/repository_locations.bzl that points to your fork while the proxy-wasm-cpp-host PR is still under review. This way, the CI tests the complete change, instead of only the Envoy part, and it signals that this PR is still blocked on the proxy-wasm-cpp-host PR.
In this particular case, the merged PR is a bit useless by itself.

authors: PiotrSikora mathetake


text:
build: update grpc to 1.34.0

Signed-off-by: Asra Ali asraa@google.com
Commit Message: Updates gRPC dependency to version 1.33.2. Also updates upb as a requirement, and removes a stale patch.
Additional Description:

Side effect, fixes fuzz bug.
gRPC adds frame size negotiation for ALTS. Used default.

Risk Level: Low, but not non-existent? There was a gRPC default change.
Testing: Added regression test for fuzz bug.
Fixes:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27307

/lgtm deps

Looks like there was a failure in test, after fixing, it seems there's a fake handshake shutdown failure due to a timeout. investigating.

@markdroth Hi Mark, quick question. I'm trying to update gRPC and ran into a timeout failure in IpVersions/AltsIntegrationTestClientInvalidPeer.ClientValidationFail/IPv4 when trying to shutdown the fake handshake server. Just curious, do you have a lead on this? Tried to check if there was anything different about Shutdown from 1.27 to 1.33, and couldn't find an immediate lead. Any idea here to start looking? Seems like Shutdown never returns. Thank you!

I ran into these same timeout issues on a prior attempt at https://github.com/envoyproxy/envoy/pull/13394. The comment https://github.com/envoyproxy/envoy/pull/13394#issuecomment-706363562 from @yashykt about the changed status codes looks like the closest thing I could find. We then decided to defer gRPC and bump protobuf independently

The gRPC commit for the status changes is at https://github.com/grpc/grpc/pull/22901/files

Thanks @moderation! I changed the status code already, which fixed some test issues, but not the Shutdown() timeout, which seemed independent. Let me trace through and see if onRemoteClose() is being called anywhere there or if I can relate it.

@jiangtaoli2016 @yihuazhang Sorry for asking again, I'm attempting to bump gRPC again. The HTTP response code conversions are all fixed, but the timeout remains in the ALTS integration test.
I verified that the client validation actually fails, and that the issue is that Shutdown() never returns. I experimented with adding an deadline like Shutdown(now), but no luck. The handshake seems to fail Couldn't find peer's service account in peer_service_accounts: invalid_client_identity, but I also TSI: Handshake successful: peer properties: 5
[2020-11-24 19:02:26.496][28][debug][conn_handler] [source/server/connection_handler_impl.cc:503] [C1] new connection
[2020-11-24 19:02:26.496][28][trace][connection] [source/common/network/connection_impl.cc:517] [C1] socket event: 2
[2020-11-24 19:02:26.496][28][trace][connection] [source/common/network/connection_impl.cc:625] [C1] write ready
[2020-11-24 19:02:26.496][28][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:45] [C1] TSI: doHandshake
[2020-11-24 19:02:26.496][12][trace][connection] [source/common/network/connection_impl.cc:517] [C0] socket event: 2
[2020-11-24 19:02:26.496][12][trace][connection] [source/common/network/connection_impl.cc:625] [C0] write ready
[2020-11-24 19:02:26.496][12][debug][connection] [source/common/network/connection_impl.cc:634] [C0] connected
[2020-11-24 19:02:26.496][12][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:54] [C0] TSI: doHandshake next: received: 0
[2020-11-24 19:02:26.497][12][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:45] [C0] TSI: doHandshake
[2020-11-24 19:02:26.498][12][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:79] [C0] TSI: doHandshake next done: status: 0 to_send: 10
[2020-11-24 19:02:26.498][12][trace][connection] [source/common/network/raw_buffer_socket.cc:68] [C0] write returns: 10
[2020-11-24 19:02:26.498][28][trace][connection] [source/common/network/connection_impl.cc:517] [C1] socket event: 3
[2020-11-24 19:02:26.498][28][trace][connection] [source/common/network/connection_impl.cc:625] [C1] write ready
[2020-11-24 19:02:26.498][28][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:45] [C1] TSI: doHandshake
[2020-11-24 19:02:26.498][28][trace][connection] [source/common/network/connection_impl.cc:555] [C1] read ready. dispatch_buffered_data=false
[2020-11-24 19:02:26.498][28][trace][connection] [source/common/network/raw_buffer_socket.cc:25] [C1] read returns: 10
[2020-11-24 19:02:26.498][28][trace][connection] [source/common/network/raw_buffer_socket.cc:39] [C1] read error: Resource temporarily unavailable
[2020-11-24 19:02:26.498][28][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:169] [C1] TSI: raw read result action 1 bytes 10 end_stream false
[2020-11-24 19:02:26.498][28][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:45] [C1] TSI: doHandshake
[2020-11-24 19:02:26.498][28][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:54] [C1] TSI: doHandshake next: received: 10
[2020-11-24 19:02:26.499][28][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:79] [C1] TSI: doHandshake next done: status: 0 to_send: 21
[2020-11-24 19:02:26.499][28][trace][connection] [source/common/network/raw_buffer_socket.cc:68] [C1] write returns: 21
[2020-11-24 19:02:26.499][12][trace][connection] [source/common/network/connection_impl.cc:517] [C0] socket event: 3
[2020-11-24 19:02:26.499][12][trace][connection] [source/common/network/connection_impl.cc:625] [C0] write ready
[2020-11-24 19:02:26.499][12][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:45] [C0] TSI: doHandshake
[2020-11-24 19:02:26.499][12][trace][connection] [source/common/network/connection_impl.cc:555] [C0] read ready. dispatch_buffered_data=false
[2020-11-24 19:02:26.499][12][trace][connection] [source/common/network/raw_buffer_socket.cc:25] [C0] read returns: 21
[2020-11-24 19:02:26.499][12][trace][connection] [source/common/network/raw_buffer_socket.cc:39] [C0] read error: Resource temporarily unavailable
[2020-11-24 19:02:26.499][12][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:169] [C0] TSI: raw read result action 1 bytes 21 end_stream false
[2020-11-24 19:02:26.499][12][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:45] [C0] TSI: doHandshake
[2020-11-24 19:02:26.499][12][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:54] [C0] TSI: doHandshake next: received: 21
[2020-11-24 19:02:26.500][12][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:79] [C0] TSI: doHandshake next done: status: 0 to_send: 14
[2020-11-24 19:02:26.500][12][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:100] [C0] TSI: Handshake successful: peer properties: 5
[2020-11-24 19:02:26.500][12][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:103] [C0]   certificate_type: ALTS
[2020-11-24 19:02:26.500][12][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:103] [C0]   service_account: peer_identity
[2020-11-24 19:02:26.500][12][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:103] [C0]   rpc_versions:

[2020-11-24 19:02:26.500][12][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:103] [C0]   alts_context:
peer_identity*local_identity2

[2020-11-24 19:02:26.500][12][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:103] [C0]   security_level: TSI_PRIVACY_AND_INTEGRITY
[2020-11-24 19:02:26.500][12][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:112] [C0] TSI: Handshake validation failed: Couldn't find peer's service account in peer_service_accounts: invalid_client_identity
[2020-11-24 19:02:26.500][12][debug][connection] [source/common/network/connection_impl.cc:117] [C0] closing data_to_write=0 type=1
[2020-11-24 19:02:26.500][12][debug][connection] [source/common/network/connection_impl.cc:213] [C0] closing socket: 1
[2020-11-24 19:02:26.500][12][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:232] [C0] TSI: closing socket
[2020-11-24 19:02:26.500][12][trace][main] [source/common/event/dispatcher_impl.cc:213] item added to deferred deletion list (size=1)
[2020-11-24 19:02:26.500][28][trace][connection] [source/common/network/connection_impl.cc:517] [C1] socket event: 3
[2020-11-24 19:02:26.500][12][debug][client] [source/common/http/codec_client.cc:96] [C0] disconnect. resetting 0 pending requests
[2020-11-24 19:02:26.500][28][trace][connection] [source/common/network/connection_impl.cc:625] [C1] write ready
[2020-11-24 19:02:26.500][28][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:45] [C1] TSI: doHandshake
[2020-11-24 19:02:26.500][28][trace][connection] [source/common/network/connection_impl.cc:555] [C1] read ready. dispatch_buffered_data=false
[2020-11-24 19:02:26.500][12][trace][main] [source/common/event/dispatcher_impl.cc:90] clearing deferred deletion list (size=1)
[2020-11-24 19:02:26.500][28][trace][connection] [source/common/network/raw_buffer_socket.cc:25] [C1] read returns: 0
[2020-11-24 19:02:26.500][28][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:169] [C1] TSI: raw read result action 1 bytes 0 end_stream true
[2020-11-24 19:02:26.500][28][debug][connection] [source/common/network/connection_impl.cc:602] [C1] remote close
[2020-11-24 19:02:26.500][28][debug][connection] [source/common/network/connection_impl.cc:213] [C1] closing socket: 0
[2020-11-24 19:02:26.500][28][debug][connection] [source/extensions/transport_sockets/alts/tsi_socket.cc:232] [C1] TSI: closing socket
[2020-11-24 19:02:26.500][28][trace][main] [source/common/event/dispatcher_impl.cc:213] item added to deferred deletion list (size=1)
[2020-11-24 19:02:26.500][28][debug][conn_handler] [source/server/connection_handler_impl.cc:164] [C1] adding to cleanup list
[2020-11-24 19:02:26.500][28][trace][main] [source/common/event/dispatcher_impl.cc:213] item added to deferred deletion list (size=2)
[2020-11-24 19:02:26.500][28][trace][main] [source/common/event/dispatcher_impl.cc:213] item added to deferred deletion list (size=3)
[2020-11-24 19:02:26.500][28][trace][main] [source/common/event/dispatcher_impl.cc:90] clearing deferred deletion list (size=3)
[2020-11-24 19:02:28.478][24][info][main] [source/server/drain_manager_impl.cc:70] shutting down parent after drain
[2020-11-24 19:02:31.442][24][debug][main] [source/server/server.cc:196] flushing stats
[2020-11-24 19:02:36.446][24][debug][main] [source/server/server.cc:196] flushing stats
[2020-11-24 19:02:41.451][24][debug][main] [source/server/server.cc:196] flushing stats
[2020-11-24 19:02:46.454][24][debug][main] [source/server/server.cc:196] flushing stats

Confirmed that https://github.com/grpc/grpc/commit/837c4ce589924640bbc395128ba07cbeffdd5b5c#diff-ff0681fdeb3cda181d2ac2d4b80915cd is not 100% the root cause. With a patch that reverts this commit, the tests crash, so the patch did it's part in preventing the crash. As far as the timeout, still no dice.

@jiangtaoli2016 may be able to help with the ALTS problem.

Just back from OOO. It looks like the problem is at the shutdown of of the FakeHandshakerService. @apolcyn last changed it with this PR.
@asraa Could you revert that PR and try and see if it can shutdown correctly?

@jiangtaoli2016 I do not think the PR [https://github.com/grpc/grpc/commit/528d50ab1564b86e44e1a30041581d2d0b57e63d] is the culprit because it is introduced in gRPC version 1.26, and ALTS integration test still works with version 1.27.

update: @jiangtaoli2016 helped debug and fixed the shutdown happening in client validation fail. change pushed
however, another timeout is happening in CheckAltsVersion. https://github.com/envoyproxy/envoy/blob/5e2a0e6a5c03774bf4d12ac2ebddfa59631a1a27/test/extensions/transport_sockets/alts/alts_integration_test.cc#L60 is stuck in an infinite loop waiting for a client request. will get back to this later.

@asraa, regarding the timeout happened in CheckAltsVersion, I think after extracting the RPC version from the first client and server handshake message at line (https://github.com/envoyproxy/envoy/blob/master/test/extensions/transport_sockets/alts/alts_integration_test.cc#L73), it should return OK, instead of hang there.

@yihuazhang Thank you so much! Tests pass :)

@asraa can you take a look at format etc?

@asraa gRPC 1.34.0 is out if you want to try and jump all the way to latest - https://github.com/grpc/grpc/releases/tag/v1.34.0

Will do! I'm not sure why I keep hitting CI errors. Looks like one after the merge.

Bumped to 1.34.0. It looks like I'm hitting this https://github.com/envoyproxy/envoy/blob/f8b234bb3c416d04ae940ff3cab8649dade78841/source/common/grpc/async_client_impl.cc#L113 in clang_tidy.

CI is passing besides the existing clang_tidy issue

/cc @mattklein123 as https://github.com/envoyproxy/envoy/blob/f8b234bb3c416d04ae940ff3cab8649dade78841/source/common/grpc/async_client_impl.cc#L113 is marked as his TODO

/lgtm deps

Upstream merged, clang-tidy is still pre-existing.

@mattklein123 @moderation Sorry for bumping this again, but merged in main, clang-tidy is still failing on existing TODO

@mattklein123 @moderation Sorry for bumping this again, but merged in main, clang-tidy is still failing on existing TODO

OK let's force merge given it's an existing issue.

OK let's force merge given it's an existing issue.

authors: asraa htuch jiangtaoli2016 markdroth mattklein123 moderation yihuazhang


text:
listener: deprecate use_proxy_proto

Commit Message:
listener: deprecate use_proxy_proto
Signed-off-by: Taylor Barrella tabarr@google.com
Additional Description:
Risk Level: Low
Testing: grep for occurrences of use_proxy_proto
Docs Changes: Updated references to use_proxy_proto to refer to the listener filter instead, as well as sample configuration
Release Notes:
#14085
Deprecated: envoy_v3_api_field_config.listener.v3.FilterChain.use_proxy_proto was deprecated because the proxy protocol listener filter can/should be added at the listener level instead

/retest

Hey @lizan it seems one of the tests has been stuck for hours, what do I do?

Opened #14445 although that unstuck this one too (is there a way for me to do that without opening a new PR?)

Can you try merging main into this PR?

(just a heads up that I plan to be taking a break from tomorrow to 1/4)


text:
docs: kick-off 1.17.1-dev.

Signed-off-by: Piotr Sikora piotrsikora@google.com

dupe of https://github.com/envoyproxy/envoy/pull/14824 need fix some CI scripts altogether.

@lizan Thanks!

authors: PiotrSikora lizan


text:
matching: fix regex engine initialization order

Commit Message: matching: fix regex engine initialization order
Additional Description: When Envoy is started with stats_config.histogram_bucket_settings in bootstrap configuration, it asserts/exits on startup.
Risk Level: Low
Testing: Manual, unit/integration testing
Docs Changes: Done
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #22258 ]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

This is a dup of https://github.com/envoyproxy/envoy/pull/21972. Let's land that other PR.


text:
Add example for OpenTelemetry Tracer

Commit Message: Add example for OpenTelemetry Tracer
Additional Description: This is the Jaeger Tracing demo, but with OpenTelemetry tracing instead. Like the Jaeger Tracing demo, it pulls up 3 Envoy instances with OTLP tracing enabled, then also runs the OpenTelemetry Collector.
Risk Level: Very low (just an example)
Testing: Added verify.sh
Docs Changes: Added README.md here, but happy to add docs as well
Part of https://github.com/envoyproxy/envoy/issues/9958

hi @AlexanderEllis thans for working on this - very useful - headsup that these sandboxes can take quite a bit of back and forth
we will definitely need some rst docs for this - im happy to help putting these together
i see this is WIP still - do you want me to give it a first pass now ?

Hi @phlax , sounds good to me! Last thing I'm fixing is just ensuring the verify script passes in the pipeline as well — I think I was running into permissions issues with the yaml config for the collector, but I've added a bit to (hopefully) fix that part.
A first pass would be great! I'll mark this as review, and happy to iterate as we go :) Thanks!

@phlax Still running into trouble with the verify script in the CI pipeline, though things are working locally 🤔  I'm currently seeing the following:
opentelemetry_collector_1  | Error: failed to get config: cannot resolve the configuration: unable to read the file file:/etc/otel-collector-config.yaml: open /etc/otel-collector-config.yaml: permission denied
opentelemetry_collector_1  | 2022/08/18 20:03:29 collector server run finished with error: failed to get config: cannot resolve the configuration: unable to read the file file:/etc/otel-collector-config.yaml: open /etc/otel-collector-config.yaml: permission denied

I think I'm adding this file correctly in the Dockerfile:
  opentelemetry_collector:
    build:
      context: .
      dockerfile: Dockerfile-opentelemetry-collector
    command: ["--config=/etc/otel-collector-config.yaml"]
    volumes:
    - ./otel-collector-config.yaml:/etc/otel-collector-config.yaml
    ports:
    - "${PORT_COLLECTOR_ZPAGE:-55679}:55679"

Any suggestions on this? I'm far from a docker expert, and any help would be appreciated.

Any suggestions on this? I'm far from a docker expert, and any help would be appreciated.

i will review tomorrow - but off hand my guess is that the permissions in CI are different.
before running it the permissions/umask are restricted - in ci/do_ci.sh
 191   umask 027
 192   chmod -R o-rwx examples/

it does this to simulate an env (ie google) where home dirs are shared and perms are stricter

following up on this - im just looking at flakes in other examples
the shared/tracing Docker image is probably best avoided - its really not an example of best practice as it has 2 processes running inside the container
im just looking at how we can unpick this from existing examples

im realizing that this PR is copying out some of the issues in other tracing examples
it was on my agenda to rewrite these - esp for zipkin as it can flake - but also for the jaeger ones
im most of the way through rewriting the zipkin example - which can be seen here #22771, altho its going to take me a while to complete

zipkin sandbox update is complete - i would use that (ie in PR #22771 as it hasnt yet landed) as the basis for this sandbox
updated docs for the zipkin sandbox can be seen here https://storage.googleapis.com/envoy-pr/87b2474/docs/start/sandboxes/zipkin_tracing.html

With OpenTelemetry now being supported (thanks @AlexanderEllis!), I think we can / should deprecate the Jaeger and OpenTracing extensions and sandboxes. Discussion at https://github.com/envoyproxy/envoy/issues/9958. @cgilmour is planning to update the Datadog tracer to remove the OpenTracing dependency which will allow for its removal - https://github.com/envoyproxy/envoy/issues/21083#issuecomment-1196172567

I think we can / should deprecate the Jaeger and OpenTracing extensions and sandboxes

it would be good to clarify which sandboxes these are - there are a few other tracing sandboxes (eg skywalking, zipkin)
either way - i think the pattern that the updated zipkin sandbox uses is roughly the pattern we want for the tracing sandboxes

@AlexanderEllis was hoping to ping you on slack - but didnt find you there - so i guess ill post here
@nguyenptk has been working on a Kafka sandbox and has got a pretty good idea how the sandbox docs/verify work
im wondering if it would be helpful for him and I to take over this PR - im thinking we can use the settings you have set up here but with the zipkin example as a template
I really appreciate the work you have done/are doing on the OT extension - so happy to work on this if it is helpful

Hey @phlax , sorry for the delay here (day-job got busy), but that would be great! It sounds like the new Zipkin example would be great to reuse here, and from the sounds of it, the only differences would be 1) the OpenTelemetry Tracer config 2) seeing the traces and 3) viewing the OpenTelemetry collector page.
Happy to help with any questions about the setup 👍  Thanks again!

closing this as #22988 has now landed

authors: AlexanderEllis moderation phlax


text:
test: hopefully fixing a tsan flake

Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

https://dev.azure.com/cncf/envoy/_build/results?buildId=135890&view=logs&j=d1f76054-8f79-554b-6f4a-11d6a63b8e00&t=a193292f-96b1-53c3-0505-a923ddcc3f84&l=1081
https://dev.azure.com/cncf/envoy/_build/results?buildId=135894&view=logs&j=d1f76054-8f79-554b-6f4a-11d6a63b8e00&t=a193292f-96b1-53c3-0505-a923ddcc3f84&l=887


text:
limit calculated sampling exponent

Commit Message: Limit calculated sampling exponent
Additional Description: Ensure that calculated sampling exponend stays below a certain limit
Risk Level: Low
Testing: Unit test, manual
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #37199]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

/assign @yanavlasov

Hi @yanavlasov @wbpcode! My colleague @samohte prepared back-ports for this bug to the relevant versions. Would be great if we can get those in. Thanks!

1.30 https://github.com/envoyproxy/envoy/pull/37284
1.31 https://github.com/envoyproxy/envoy/pull/37283
1.32 https://github.com/envoyproxy/envoy/pull/37281

authors: joaopgrassi samohte soulxu


text:
config: logging LDS file on config failure

This mostly as a follow-on to #6933, it makes it less annoying to diagnose configuration issues when writing new integration tests by

fast-failing if the LDS update is rejected
timing out if there's some other LDS failure
printing the LDS file if it was a valid proto but rejected for other reasons.

Risk Level: Low (log tweak + test changes)
Testing: existing tests pass (new tests are easier to write)
Docs Changes: n/a
Release Notes: n/a

@snowp for non-googler eyes on.

authors: alyssawilk jmarantz


text:
upstream: fix the header file path typo

Description: Fix the header path
Risk Level: LOW
Testing: N/A
Docs Changes: N/A
Release Notes: N/A

/assign htuch


text:
sds: add validation callback for all secret providers

This adds an implementation of addValidationCallback for all secret providers. This is a no-op, unless the secret provider is a `CertificateValidationContextSdsApi.
Envoy crashes when trying to add a validation callback to CertificateValidationContextProvider due to a bad dynamic cast. When certificate_validation_context_provider_ isn't a CertificateValidationContextSdsApi, we no-op.
Fixes: #7892 and OSS-Fuzz Issue
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17001
Testing: add corpus entry
Signed-off-by: Asra Ali asraa@google.com

@snowp @JimmyCYJ can you take a look and see if this lines up with the SDS intended behavior with respect to the config in the testcase?

/retest

@JimmyCYJ yes it is generated by oss-fuzz

authors: asraa lizan


text:
chore: sort the result of alpnProtocols

          should we sort this?

Originally posted by @zirain in https://github.com/envoyproxy/gateway/pull/2887#discussion_r1520896894

According to the rfc:

It is expected that a server will have a list of protocols that it supports, in preference order,

If this is sorted alphabetically, then it's not possible for the user to decide the preference order.

then should point out this in API doc, and make sure everything in excepted order.

authors: liorokman zirain

repo: envoyproxy/gateway


text:
Make jwt fetch more reliable

Async is useful because it will not block requests with jwt fetches, will not need to jwt fetch per thread Retrying once after a failed fetch is also useful

probably blocked on https://github.com/envoyproxy/gateway/pull/1601 which fixes some issues in the conformance tests in the newer v0.8.0-rc1 version that was recently added

authors: arkodg jackkleeman


text:
🛑 Live Results is down

In c902e24, Live Results (https://chrono.live) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Live Results is back up in 1a13206 after 6 minutes.

repo: enyone/upptime


text:
FFT support?

Any plants to incorporate [fft~] and the like?

It's in the pipeline https://github.com/enzienaudio/heavy/issues/12

authors: diplojocus jeppius

repo: enzienaudio/heavy

license: ISC


text:
Read Performance concurrency issue

https://github.com/eo-cqrs/xfake/blob/ecd9054d28728e9b8653e61b70c4b81580ca3d56/src/main/java/io/github/eocqrs/xfake/InFile.java#L85-L95
better replace to
...
final ReentrantReadWriteLock rwlock = new ReentrantReadWriteLock();
...
 public XML xml() throws Exception {
   this.rwlock.readLock().lock()
     try {
       return new XMLDocument(
         new TextOf(
           new File(
             this.name
           )
         ).asString()
       );
     } finally {
       this.rwlock.readLock.unlock();
     }
   }
 }

@l3r8yJ thank you for reporting this. I'll assign someone to take care of it soon.

@h1alexbel this is your task now, please go ahead. Deadline (when this ticket should be closed) is 2023-06-05T06:12:21.434266.
Estimation here is 60 minutes, that's how much you will be paid.
Remember, you don't have to solve everything in this ticket - you can solve it partially and leave todo markers in the code, which will become future tasks.
If you have any questions don't ask me, I'm not a technical person. Open new tickets instead.
If you don't have time or simply don't want to work on this, you can always resign.

@l3r8yJ nice, I will try to apply it!

@l3r8yJ the puzzle #26 is still not solved.

@h1alexbel thank you for resolving this ticket. I've just added it to your active invoice. You can always check all your invoices and more on the Contributor Dashboard.

@l3r8yJ the only puzzle #26 is solved here.

repo: eo-cqrs/xfake