Lost data on "summary_table_filed"

Hi, I have a problem with "summary_table_filed"
My configuration:
name: Flatline DA field action.type:(auth OR provision) equal to zero > 15min
type: flatline
es_host: elastic
es_port: 9200

index: operations-*

use_count_query: false

timeframe:
  minutes: 3

query_key: action.type

threshold: 100

filter:
- query:
    query_string:
      query: "action.type:(auth provision)"

doc_type: "log"

summary_table_fields:
 - carrier
 - operator

alert_text_type: exclude_fields

# (Required)
# The alert is use when a match is found
alert:
- "email"
email<EMAIL_ADDRESS>
On the console I see that rules count right:
INFO:elastalert:Sent email to<EMAIL_ADDRESS>INFO:elastalert:Ignoring match for silenced rule Flatline DA field action.type:(auth OR provision) equal to zero > 15min.provision
INFO:elastalert:Ignoring match for silenced rule Flatline DA field action.type:(auth OR provision) equal to zero > 15min.auth
INFO:elastalert:Ran Flatline DA field action.type:(auth OR provision) equal to zero > 15min from 2017-08-06 13:45 EEST to 2017-08-06 13:53 EEST: 228 query hits (195 already seen), 3 matches, 1 alerts sent
INFO:elastalert:Sleeping for 59.667277 seconds

but on the email on table "summary_table_filed" data lost or often not displayed:

Aggregation resulted in the following data for summary_table_fields ==> ['carrier', 'operator', 'count']:
+--------------+-------------------+-------+
| carrier        | operator        | count |
+========+==========+=====+
| None         | None              | 1       |
+--------------+-------------------+-------+
Flatline DA field action.type:(auth OR provision) equal to zero > 15min
An abnormally low number of events occurred around 2017-08-06 14:03 EEST.
Between 2017-08-06 14:00 EEST and 2017-08-06 14:03 EEST, there were less than 100 events.

Sometimes the data are present:

Aggregation resulted in the following data for summary_table_fields ==> ['carrier', 'operator', 'count']:
+--------------+------------------------+-------+
| carrier       | operator                | count |
+========+==============+====+
| my_carrier_1 | my_operator_1 | 1     |
+--------------+-------------------------+-------+
Flatline DA field action.type:(auth OR provision) equal to zero > 15min
An abnormally low number of events occurred around 2017-08-06 13:49 EEST.
Between 2017-08-06 13:46 EEST and 2017-08-06 13:49 EEST, there were less than 100 events.

I have 2 different carriers and operator when event's less threshold, I want to see which operator's and carrier has become smaller than threshold(focus on field action.type)

Okey, I modified config (reconfigure query_key and summary_table_fields):
query_key:
 - action.type
 - operator
....
summary_table_fields:
 - carrier
 - operator
 - action.type

On the console, I see 4 different keys:
[INFO:elastalert:Ignoring match for silenced rule Flatline DAR field action.type:(auth OR provision) equal to zero > 15min.auth, my_operator_1
INFO:elastalert:Ignoring match for silenced rule Flatline DAR field action.type:(auth OR provision) equal to zero > 15min.auth, my_operator_2
INFO:elastalert:Ignoring match for silenced rule Flatline DAR field action.type:(auth OR provision) equal to zero > 15min.provision, my_operator_1
INFO:elastalert:Ignoring match for silenced rule Flatline DAR field action.type:(auth OR provision) equal to zero > 15min.provision, my_operator_2]

I have email, but table empty:

Aggregation resulted in the following data for summary_table_fields ==> ['carrier', 'operator', 'action.type', 'count']:
+--------------+-------------------+-------------+-------+
| carrier      | operator          | action.type | count |
+==============+===================+=============+=======+
| None         | None              | None        | 1     |
+--------------+-------------------+-------------+-------+
Flatline DAR field action.type:(auth OR provision) equal to zero > 15min
An abnormally low number of events occurred around 2017-08-06 14:54 EEST.
Between 2017-08-06 14:51 EEST and 2017-08-06 14:54 EEST, there were less than 100 events.
@timestamp: 2017-08-06T11:54:51.408497Z
count: 2
key: auth, my_operator_1
num_hits: 299
num_matches: 5

Table is empty but the key is set

You don't appear to be using aggregation, so your table will always contain a bunch of count=1 entries, and is not really a useful "table".
Regarding accessing the query_key values, you need to use key, and it's only available as a comma separated string.
summary_table_fields:
 - key

Which, since you don't have aggregation set, is always going to be a 1 entry table. you might as well do
alert_text: "type, operator: {}"
alert_text_args: [key]

It would be a nice feature to be able to use compound query_keys in a table rather than just as a single string. That's definitely on the long list of nice to haves.

@Qmando, thank you for your answer!


Submit challenge 20210622 counting coins

Closes #55

@drkennetz  Would you mind downloading it and trying to run ./run_tests? I want to make sure it will pull down the dependencies and set up properly on someone else's system.


Support for named single-file volumes

Single-file Docker volumes are great to replace / insert configuration files.
But the current implementation has some major limitations:

you cannot replace the container without the file at place. (this makes the container dependant on the structure of the host fs).
two containers cannot share the same file.
a single-file volume is not listed as a volume.

Use cases for single-file volumes cannot be transformed into use cases with folder-based volumes without forcing the application to restructure their file system.

Single file mounts are a feature that only exists on Linux, and are not available on other Unix platforms or on Windows, so I am not sure if adding this is a generic feature is a good idea.
Can you not use symlinks to have the same effect for configuration files? Build the container with a symlink pointing at /config/.../config-file and then mount a config volume in /config?

Ok, I was not aware of the plattform-specific limitations of this feature.
Working with symlinks like shown indeed solves the problem from the perspective of the image author.
From the user perspective this cannot be achieved for images that are not designed in this way. A lot of public Docker images therefore loose their flexibility in terms of advanced configuration. Apart from the comfort Docker provides, it just feels odd that switching one config file requires a whole new Docker image.

I'll leave a comment here:
MySQL (Or pretty much any DB)
NginX (Or pretty much any web front end)
Jenkins (And pretty much any other CI/CD Pipeline Application)
The list goes on and on and on of use cases where you need to be able to configure the application running within the docker container without creating 100's of copies of that same docker container.
In my Fortune 500 org we have about 100 Apache Containers running with slightly different config files for each customer (hard separation requirements by the customers require we don't run multiple customers in the same apache instance as Virtual Hosts).
I cannot move these to swarm / volume drivers to take advantage of orchestration / container failover without building a hundred or so one-off containers and then coding an entire stop/start infrastructure (that has to be modified each time a new customer onboards) for them.
This is one of the most simple/basic tasks with single server docker.

Can you use docker config for this use case?
https://docs.docker.com/engine/swarm/configs/
On 7 Aug 2017 04:34, "Douglas Wagner"<EMAIL_ADDRESS>wrote:

I'll leave a comment here:
MySQL (Or pretty much any DB)
NginX (Or pretty much any web front end)
Jenkins (And pretty much any other CI/CD Pipeline Application)
The list goes on and on and on of use cases where you need to be able to
configure the application running within the docker container without
creating 100's of copies of that same docker container.
In my Fortune 500 org we have about 100 Apache Containers running with
slightly different config files for each customer (hard separation
requirements by the customers require we don't run multiple customers in
the same apache instance as Virtual Hosts).
I cannot move these to swarm / volume drivers to take advantage of
orchestration / container failover without building a hundred or so one-off
containers and then coding an entire stop/start infrastructure (that has to
be modified each time a new customer onboards) for them.
This is one of the most simple/basic tasks with single server docker.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/moby/moby/issues/30310#issuecomment-320560959, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAdcPA8HlRh2z3fRDeoCoJkYu3ergtJjks5sVoXNgaJpZM4LpLc5
.

@justincormack Yea, so just to loop back around on this (apologies for the thread necro) Docker Config should (and in my case does) fix the use case for single file "volume" (bind) mounts.
Not sure how I missed that little feature but it does fix all the use cases in my prior message.
Thanks for the direction on this.

Yes, I think we should close this issue now that we have both configs and secrets for services. In addition, we added the --mount option for docker run (already existed for docker service create), which will produce an error if the source file/directory doesn't exist, instead of silently ignoring and creating a directory on the host.
Closing this issue, but feel free to discuss.

@thaJeztah You support neither subpaths of folder-based named volumes (#32582), nor single-file named volumes (#30310), nor mounting of volumes from the filesystem where a docker client binary is invoked (out of the box anyway). As a result it's impossible to put a file in a named volume and then simply mount that single file into a target location adjacent to other, non-volume files. Could you please fix whichever of #32582 and #30310 is easiest to fix?
I can't use host volumes because they basically reduce a shared docker host to SPOF filesystem-wise, which defeats the point of containerization.


Magento 221 compilation error

Steps to reproduce

composer require rubic/magento2-module-clean-checkout
bin/magento setup:upgrade
bin/magento setup:di:compile

[ReflectionException]
  Class Hybridauth\HybridauthFactory does not exist

  [ReflectionException]
  Class Hybridauth\HybridauthFactory does not exist

  [RuntimeException]
  Source class "\Hybridauth\Hybridauth" for "Hybridauth\HybridauthFactory" generation does not exist.

You should do a composer update, just fixed that issue in a new version.
On Dec 6, 2017 5:41 PM, "Calin"<EMAIL_ADDRESS>wrote:

Steps to reproduce

composer require rubic/magento2-module-clean-checkout
bin/magento setup:upgrade
bin/magento setup:di:compile

[ReflectionException]
Class Hybridauth\HybridauthFactory does not exist
[ReflectionException]
Class Hybridauth\HybridauthFactory does not exist
[RuntimeException]
Source class "\Hybridauth\Hybridauth" for "Hybridauth\HybridauthFactory" generation does not exist.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/danslo/CleanCheckout/issues/7, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAtY7SvvhhpQ1nLuffsKREDQMODWLpvPks5s9sPGgaJpZM4Q4Ny-
.

Ah perfect, thanks for quick reply @danslo


Configurations: make Makefile tmpl files non-links

This commit updates Configurations/README.md and turns the Makefile
templates into non-links.
The motivation for this is that not all template exist in the directory
leading to 404 Not found errors when accessed.

This pull request is ready to merge

Merged to master.  Thanks for the contribution.


test_sort.sh not found

Apologies if this was already reported, I didn't find anything in the reported issues
version 2.26.0
bash: test-sort.sh: No such file or directory
test/test.sh line 59:
cd slop; bash test-sort.sh; cd ..
I think it should be
cd sort; bash test-sort.sh; cd ..

This should be fixed in git.
test/test.sh is completely rewritten.


computeshader crash

the executable computeshader crash with TDR nvidia (newest driver)

Thanks for attention. My GPU is gtx770 (Kepler) with 364.51 driver version (newest driver and certif. WHQL). Samples compile normally and almost executable run perfectly, but this executable crash with TDR driver...

Same bere,  George 720

@andreluizbarbieri , @amerkoleci: Do the compute examples still crash with the most recent drivers?

Closing due to inactivity. If this still happens please open a new issue.


Add save button to CoregistrationUI

https://user-images.githubusercontent.com/2046265/150696200-b197e1c4-a795-4f19-a02d-5e2b5f1fb265.mov

CoregistrationUI gained a Save button, which will save the current fiducial selection into the standard location subjects_dir/subject/bem/subject-fiducials.fif). It is not possible to pick a custom location. (Will be loaded automatically next time the GUI is started)
The Load button for fiducials got a more verbose label
Added a quite verbose description to help the user understand what fiducials are currently loaded and how to discover them in the figure
For writing fiducials, we now create a proper DigMontage (instead of a list of dicts, as was done previously) -> should be more robust!
_dock_add_file_button method gained two new parameters, filter to only allow filenames meeting the filter criteria, and initial_directory to point the file picker to the specified initial directory. I've adjusted the trans file pickers accordingly (loading / saving; initial directory for both is now the parent directory of the digitization source)
_dock_add_label now enables line wrapping
Dock width is limited to 350 pixels
Coregistration class gained a _fid_filename attribute to store the filename of the loaded fiducials file
Some documentation updates

This was more or less a quick hack to remove a blocker for @SophieHerbst and me.
Things that would need to be addressed in a followup PR:

Behavior when subject is changed. Currently, the previously-loaded fiducials remain loaded (albeit the label text changes and makes clear that they are "custom"). We'd need to factor out part of __init__() into a new method.
Right dock is too narrow for me on macOS. This is however not because the 350 pixel limit I set is too small per se, but we're somehow making bad use of the available space. We can do better!
I'd like to rework the subjects_dir picker as well.

I also discovered a bug: Loading a trans doesn't automatically apply it (can be seen in the last few seconds of the video) (fixed in #10224)
cc @GuillaumeFavelier

That looks great @hoechenberger! Very explicit now.

I would not even allow "load from custom location". I would just have "load" and "save". If there are advanced users who really want to use custom locations, they can mv files as needed. I'd assume YAGNI on all the custom-location stuff

I would not even allow "load from custom location". I would just have "load" and "save". If there are advanced users who really want to use custom locations, they can mv files as needed. I'd assume YAGNI on all the custom-location stuff

Oh I thought this was a use case in your lab, which was actually the only reason why I added that 😅 But we did have a Load thingie before. So … shall I get rid of it? We auto-load anyway if the file can be found in the standard location.

But we did have a Load thingie before. So … shall I get rid of it? We auto-load anyway if the file can be found in the standard location.

I would keep both load and save. Load allows resetting to the file-saved locations for example if you've done some clicking around to change the positions.

I would keep both load and save. Load allows resetting to the file-saved locations for example if you've done some clicking around to change the positions.

Ah ok, so we keep the ("a") Load button, but don't allow for custom files? We only (re)load from the standard location?
Sorry if these questions seem a little trivial, just trying to ensure there's no misunderstanding!

Yeah, I think just load/save buttons that operate on the standard location are probably good enough.

Closing in favor of #10242


write request should retry other disk when writing disk is busy.

Is your feature request related to a problem? Please describe.
when disk is busy, writing request will block until timeout, which will cause write slow.
Describe the solution you'd like
add qos for disk, when limit is arrived,  make write request to retry other disks.

Can I work on this?
I am relatively new to open source. So need to know more about the issue

Can I work on this? I am relatively new to open source. So need to know more about the issue

this issue a little complicated and need consider the requirement of application, thus may not suit for you, I'll introduce some other issue ,how about this one #1541


Repository credentials produce "Unknown build parameter" error

Starting with version 1.4 unrecognized parameters lead to an exception (see #28).
When using the gradle repository credentials feature, locally I enter the username and password (let's say they are called nexusUsername and nexusPassword as my repository is called nexus) in my ~/gradle.properties and everything works fine.
But when running on CI (gitlab in my case), I have the credentials of a technical user as secret CI/CD variables and pass them via -PnexusUsername=$TECHNICAL_USER_NAME -PnexusPassword=$TECHNICAL_USER_PASSWORD to gradle.
Then I receive the following exception: Unknown build parameter: nexusPassword
What would be your advice to handle this situation?

This is the new parameter validation feature. To get the old behavior, you can turn it off as described here:
https://gradlex.org/build-parameters/#disable-build-parameter-validation
The feature checks that what you pass with -P is actually declared as build parameter (e.g. to catch typos when you use this as user on the command line). So if you do not want to turn it off, you should:

Declare nexusUsername and nexusPassword as build parameters (even if you never access them through the generated extension).
You may also consider accessing the parameters through the extension to get the user/passwords and pass them to Gradle (similar to what is done in the example in the primer). Then you can directly couple them to the EVV variables you use on CI and do not need a special Gradle command line there: https://gradlex.org/build-parameters/#deriving-parameter-values-from-environment-variables (this is what I would do)

Thanks for the detailed answer, which helped me resolve the problem.
For now I went with disabling the validation, but I will certainly keep the second option in mind.


Updated app-bar to support the IconStyle prop of iconButtons

Your PR didn't pass TravisCI check for some reason.

Yep! callemall:master had couple more commits recently to fix the jsx-quotes rule for ESLint. That's where your TravisCI build is failing. If you rebase from callemall:master you should be good to go!

@mullwaden Why did you close this PR?


Speed up rendering on school overview dashboard

Splitting this issue out from #378.

https://github.com/codeforamerica/somerville-teacher-tool/issues/378#issuecomment-173748903
https://github.com/codeforamerica/somerville-teacher-tool/issues/378#issuecomment-173750887

Benchmark:

Data: Demo data, 30 students
Browser: Internet Explorer via Browserstack
4 filters total across 2 categories:

Homeroom: 101 and 102
STAR Reading: < 25th percentile and 25th - 50th percentiles

Overview
Rendering is looking fairly snappy on Chrome and Firefox. I wanted to try to measure the impact of the previous commits on Internet Explorer, since:

that is how our users experience the app, and
the app will be slower on Internet Explorer

Setup
I used Browserstack to simulate IE 11. The experience was extremely slow. It was unusable before the performance refactor and barely usable afterwards. I hope this is due in part to the remote browser-within-a-browser nature of Browserstack.
I suspect that is the case, because our partners at Somerville Public Schools reported that the filters were a bit slow, but not unusable, before the refactor.
Open to ideas for better ways to profile performance in Internet Explorer from a Mac. Any thoughts on this @kevinrobinson?
Using both versions of the code, I clicked three filters in one category on, then clicked them each off again, and then did the same for a second category.
Results
Before refactor (previous two commits):

After refactor (previous two commits):

@alexsoble Woah, that's rough!  That's a really nice improvements over where we started, and the OR filters UX look great to me.
I just tried out BrowserStack (awesome!), and I'm seeing ~2sec latency on adding and removing filters on IE11 on a Windows 10 box.  So not quite as bad, but when I tried to profile I got lots of lag in the developer tools lag and "long running script" warning.
One thing we should try is swapping in the production build of React.  All those nice warnings in development mode (eg., missing 'key' attributes, missing props) are stripped out in the production build and there's a significant performance difference.  Right now the asset pipeline is minifying the development version of React.  You can see this in the console in production:

There's a commit here that swaps in the rails-react gem that might be worth trying, or more simply we could just branch which asset is included based on Rails env: https://github.com/kevinrobinson/somerville-teacher-tool/commit/26c3931c410f8ff8fd58c5292d25277d033c2371.
So maybe we can try that next week, see where that gets us, and then if it's still too laggy we can look further.  It also might be useful to see if the computation, rendering of filters, or rendering of tables is contributing more to the slowdown (the table had this hack in it initially to keep using the jQuery tablesorter, which we could improve on if rebuilding the table each time is too expensive).
Also, for background, do users prefer using IE11, or is there a technology or policy issue?

@kevinrobinson Thanks for pointing out the React development/production build fix.
The school system generally seems to be a Windows/IE world. All the Somerville desktops and laptops I've seen have been Windows machines. Not sure if there are technology or policy issues at play.

@kevinrobinson I cherry-picked the react-rails commit, merged, and pushed to demo/production: https://github.com/codeforamerica/somerville-teacher-tool/pull/389
I think after these optimizations, the main awkward choke point is now on page load. We are making a whole bunch of database queries. Treating discipline incident counts like tardies and absences (i.e. computing them with a nightly task and storing to the database) will cut that number down by a lot.
Merging in the rest of the experiment/star-scores branch will take a bit more time because our work overlapped a bit. We both moved chunks of code out of the main file into more modular bits. I should have looked at your STAR scores branch more carefully before refactoring! But not a huge deal, it won't take a crazy long amount of time.

@alexsoble awesome!
For page load, I wonder if there's any value in precomputing the entire
response aside from interventions and notes.  Would that be simpler, or do
you think it's better to enable other similar queries to benefit from
precomputing individual fields?
And yeah, the STAR scores branch was more a design spike than anything
else, probably my bad for not communicating about it more first. :)  I can
help out with that this week too.
On Sunday, January 24, 2016, Alex Soble<EMAIL_ADDRESS>wrote:

@kevinrobinson https://github.com/kevinrobinson I cherry-picked the
react-rails commit, merged, and pushed to demo/production: #389
https://github.com/codeforamerica/somerville-teacher-tool/pull/389
I think after these optimizations, the main awkward choke point is now on
page load. We are making a whole bunch of database queries. Treating
discipline incident counts like tardies and absences (i.e. computing them
with a nightly task and storing to the database) will cut that number down
by a lot.
Merging in the rest of the experiment/star-scores branch will take a bit
more time because our work overlapped a bit. We both moved chunks of code
out of the main file into more modular bits. I should have looked at your
STAR scores branch more carefully before refactoring! But not a huge deal,
it won't take a crazy long amount of time.
—
Reply to this email directly or view it on GitHub
https://github.com/codeforamerica/somerville-teacher-tool/issues/383#issuecomment-174348927
.

@kevinrobinson Agreed the precomputing is a good idea for the server side. On the client side we are looking good now, even in IE! :+1:


MWPW-146263 - [Bulk Publish v2] Job Info UI

Display job info such as progress, status, and give option to copy a jobs invocation ID in the Job Results Panel. Also adds error filtering and error rework functionality.
Resolves: MWPW-146263
Test URLs:

Before: https://main--milo--adobecom.hlx.page/tools/bulk-publish-v2?martech=off
After: https://sarchibeque-mwpw-146263-job--milo--adobecom.hlx.page/tools/bulk-publish-v2?martech=off

Looking good Sean!
If doing multiple jobs, having the most recent job be at the top of the list. Otherwise I have to scroll a bunch to get to my most recent job links. Or maybe each job batch can be collapsible/expandable?


x axis tick labels are centered with tick on Android, but start at tick on iOS

iOS:

Android:

Code:
<VictoryChart responsive={true} height={200} width={width} padding={{top: 3, left: 25, right: 15, bottom: 22}}>

// VictoryArea code here
// Y Axis code here
// ....

      <VictoryAxis
         style={{ axis: { stroke: '#A4A4A4' },
         axisLabel: { fontSize: 8 },
         ticks: { stroke: '#A4A4A4' },
         tickLabels: { fontSize: 8, fill: '#999', padding: 0}}}
        />
</VictoryChart>

I don't think this is a surrounding container or padding issue in the VictoryChart tag because that shouldn't actually move the tick labels.
Is this the correct default behavior? Using 0.16.1

<VictoryTooltip /> is also affected:

Please add a +1 if you can reproduce this issue in the Latest versions<EMAIL_ADDRESS><EMAIL_ADDRESS>

:( now i have<EMAIL_ADDRESS>expo 25.0.0 in Ios the problem is the same....

@robertobrogi the version of react-native-svg will determine whether this can work properly. I know that expo-sdk is on an older version of react-native-svg. Current victory-native must use<EMAIL_ADDRESS>or higher in order to align labels properly.

I believe it's related to this issue: https://github.com/expo/expo/issues/1393


Move ERS call out of rego

Currently, we call ERS from inside rego.
Rego only supports http calls and we'd like the ability to hit ERS with grpc. Additionally this would remove some complexity from the rego input.
With this change, the new inputs to the rego would be a list of entity representations (returned from ERS) and the relevant subject mappings.

@elizabethhealy I wonder if we could not pass in subject mappings but instead inside of the builtin func call MatchSubjctMappings rpc.

MatchSubjctMappings

@strantalis has MatchSubjctMappings been implemented? i remember it was planned but hadn't heard anything about it

@elizabethhealy I think @jakedoublev implemented this a while back.
https://github.com/opentdf/platform/blob/5aef245720cb417a51622ffd1276f57163319c6d/service/policy/subjectmapping/subject_mapping.go#L163-L176

This is a good idea.


Not working for Sketch V.45

Many plugins have stopped working for this version and this is one of them :( are you going to update to match this version? Thanks.

It would be great to use this plugin again. 🤞

works for me on 45.1

@ChrissN, @userkamil, are you using the latest version of the plugin? Sketch 45 introduced a nasty bug, which has already been addressed (https://github.com/sonburn/symbol-organizer/issues/25).

@sonburn You're very right Sir, it works now. Thank you kindly.


Drag connector end when editMode is enabled

Hi Susie, thank you for this awesome d3 plugin.
I was wondering if there's a way to update the position of the connector end when the editMode is enabled. As far as I can see it is possible to change the connector end position only for the connectors which type is d3.annotationCalloutCircle. Am I right or I am missing something?
If there is no such functionality could you please guide me in such a way that I can try to add it myself and then make a pull request?
Thanks

This is a bug, I'm taking a look now. Thanks for catching this.

This should be fixed in v2.3.1

Hi Susie, I have tested out the new release and now everything is working as expected. Thank you for your time and cooperation.


Fork engine process to all CPUs

Run the engine process on all or defined number of available CPUs.

Can be closed, since it's an infrastructure related issue, which depends on the particular infrastructure implementation.


Public server url update

Update test and public server URLs. Minor rebranding fixes.

alrready impolemented in https://github.com/MerginMaps/mergin-cpp-client/pull/8


Update specs2-core, specs2-scalacheck to 4.17.0

Updates

org.specs2:specs2-core
org.specs2:specs2-scalacheck

from 4.12.12 to 4.17.0.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.specs2" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "org.specs2" }
}]

labels: test-library-update, early-semver-minor, semver-spec-minor, commit-count:1

Superseded by #123.


Support for MAVEN_OPTS

It would make sense to support the MAVEN_OPTS environment variable.
See https://github.com/apache/maven-mvnd/issues/567

Two caveats come to my mind:

I use both mvn and mvnd and I might want to have less Xmx for mvn than for mvnd will I be able to reach that?
Precendence between MAVEN_OPTS and mvnd.jvmArgs: would one replace the other? Or would we try to merge both before passing the args to java?

Two-cents drive-by comment: generally more specific settings should override more general settings. System properties are more specific than environment variables, since the former are per-JVM, while an environment can contain multiple JVMs. Similarly, between on-disk properties and environment properties I would say that the latter should take precedence, since the latter can be specificed per-process, while the former apply to all processes.
I.e., in order from highest to lower precedence:

The mvnd.jvmArgs system property.
The MAVEN_OPTS environment property.
The mvnd.properties properties file.

Afaik most software follows these rules. Examples include Spring and the AWS SDK.


Fix for #6158

Converting Vector2 to Size2 for scaling functions

Thanks. Could you squash the two commits together so that the SConscript history is not altered?
git rebase -i HEAD~2
// replace "pick" on second line (second commit) with "fixup"
// save and quit the text editor, it will rebase
git log // check that it worked
git show // same
// if all good:
git push --force

Should be good now, thank you! Getting used to the Git workflow again.


Use Service Principal secrets instead of SAS token

First of all, thanks a ton for the Addon!! Awesome work!
For long term usability, I'd like to use a service principal and client secret to authenticate azcopy.
Currently the SAS token generator only supports SAS token validity upto 7 days.
Also, using Azure Active Directory (Service Principal) is recommended over SAS token in general.
Possible Implementation:
# config.yaml
tenant_id: [TENANT-ID]
storage_url: https://[account].blob.core.windows.net/[container]/[path/to/virtual/dir]
principal_id: [PRINCIPAL-ID]
client_secret: [!secret]
delete: false

According to azcopy login documentation: we can use the cmd below to login with service principal and secret:
# Export AZCOPY_SPA_CLIENT_SECRET with the secret, then run
azcopy login --service-principal --application-id <your service principal's application ID>

Thanks for the suggestion and taking the time to write this up! I feel like there was a reason I hadn't done used SPN auth and opted for SAS tokens but can't remember for the life of me right now so I'll have to look into it!
As for the SAS token lifetime: as of a few months ago when I wrote this you could create a container SAS from the portal with a custom end date so that would definitely be a change. You should still be able to generate with PowerShell or the CLI if there is an upper limit on the portal now though.

@jak119 I totally understand. I'll use SAS for now since this is the easiest (although little bit less secure to create a SAS/SharedKey for a year/more). But for some subscription the SAS token expiry have an upper limit and is enforced by policy.
Upon more reading, for my personal free-subscription, I can configure the upper limit from the Configuration page: see How to configure SAS Expiration).
But for some subscriptions it might not be possible to change the upper limit since it's enforced my subscription level policies, which the user don't have access.
If you want I can take a look and do a PR with non-breaking config option for both SAS and SPA.

I'd certainly welcome a PR! Otherwise it may take me a few weeks to get around to this (although now I want to swap my personal implementation to SPN so there's some impetus for me).

Awesome! I'll do a PR and if possible, we can collaborate and brainstorm a bit on the config!

Hey @jak119 I created a script and updated the README in my forked repo, see this commit. But I couldn't test it with devcontainer, the start HASS task was not working for me.
Is it possible for you test it out or if you can give me some guidance on how to setup a devcontainer properly for HASS addons?

I created a script and updated the README in my forked repo, see this commit.

At first glance this looks great!

Is it possible for you test it out or if you can give me some guidance on how to setup a devcontainer properly for HASS addons?

I'm having issues with Docker on my laptop at the moment so I tried in Codespaces, but no luck. I did see home-assistant/devcontainer#34 a while back and that used to work, but isn't working at the moment. I can't tell if it's Codespaces or something else wrong. I'll give it a shot tomorrow and see if I can sort that out.

I've also tested it out on Codespaces and the home assistant task didn't work!
Let me try a local devcontainer if that works.
Also FYI, Codespaces now uses devcontainer features to implement docker-in-docker and other addons.

Oh that's good news. At the very least, it can be tested locally!
I think if we convert the home-assistant devcontainer to use devcontainer-features, it should work on every platform!
But that's a problem for home-assistant to solve.
Do you need to me to do anything?

@kforeverisback I'm finally getting around to testing your changes and having a bit of an issue. I left a comment for you in #80 pointing to the specific lines


Theme Toggle Only Affects Home Page

Description:
When the dark/light theme toggle button is switched on the home page, it successfully updates the home page to the selected theme. However, navigating to any other page does not retain or apply the selected theme. The expectation is that the toggle should provide a consistent dark/light theme experience across the entire application, not just on the home page.
Steps to Reproduce:
Go to the home page and toggle the theme to dark or light.
Confirm that the home page updates correctly.
Navigate to another page in the application.
Observe that the selected theme is not retained or applied on this other page.
Expected Behavior:
The selected theme (dark or light) should persist across all pages once toggled.
Actual Behavior:
The theme only updates on the home page; other pages remain unchanged.
Proposed Solution / Ideas:
Move theme state management to a global context or higher-level component that can propagate theme changes to all pages.
Ensure that the toggle component updates a shared state or uses a theme context accessible throughout the application.

@SaranDharshanSP can i get assigned to it ?

Kavinesh11

Hey @Kavinesh11  ! Noticed that you've already been assigned issues under two other repositories. Please complete those and raise PRs before requesting this issue. Excited to see your contributions!

Can I work on this?

I would like to work on this issue, @SaranDharshanSP. I have experience implementing the same functionality in our Youtube-clone project.


Restore a file put in trash

On my android, I deleted a synced file by accident on the left pane, so now it's in trash
I know that on a PC it's possible to restore with a drag and drop, but how would you do that on a mobile ? How do I restore my file? What will happen after 7 days ?

Hi, it should be in the trash on your laptap as well, so you can move it back from there. Can you check that you're running the v5.0.5 on both sides (in the Menu > More > About dialog).

Yes it is 5.0.5 on both sides but the trash is not synchronized and btw why would it be?
what would make the link between my android and my labtop? I did not sign in with my google account on both sides, I just opened a dropbox file on my android.

Ok, I understand. Reopening the file from Dropbox should basically restore the file from the trash. Would it be a solution ?

nop, I tried, the file sticks in the trash even after reopening, I can work with it normally but it's in the trash..
The only way I found was to reset the app.
Anyway, working with local folders seems limited to PC only

Should be fixed now.


Variable incorrectly inferred across await boundary

TypeScript Version:  3.4.0

Search Terms: enumeration async await
Code
function wait(tm: number) {
   return new Promise((resolve, reject) => {
      setTimeout(() => resolve(true), tm);
   });
}

let x: "foo" | "bar";

async function baz() {
    x = "bar";
    await wait(1000);
    if (x == "foo") {
        // erroneous: This condition will always return 'false' since the types '"bar"' and '"foo"' have no overlap.
        console.log("could be reached");
    }
}

setTimeout(() => x = "foo", 500);
baz();

Expected behavior:
Code should compile fine
Actual behavior:
Compiler believes x must be "bar" since it was assigned such at the start of the method.  However since there is an await this is not true.
Playground Link:
Playground link
Related Issues:

Duplicate of #9998.

Ah I had seen that issue but didn't read the comments in enough detail.  In particular this issue is exactly what was written up in this comment: https://github.com/Microsoft/TypeScript/issues/9998#issuecomment-439610488


Add message_stream documentation to Postmark adapter

put_provider_option/3 accepts :message_stream as an option, but this was not documented.

Thanks 🙏


Add a bootstrap-peers flag to override the default bootstrap peers

Added the flag type already : https://github.com/threefoldtech/rivine/commit/11e50ff83762cc879239f89577f2a8f278f12a2c


Clarify distinction between flowpaths and waterbodies.

Currently, the documentation of hygeo describes waterbodies in some detail but doesn't really get into the flowpath catchment realization.
I'm now realizing that this is a major oversight that needs to be corrected.
Initially, we have a 1:1 correspondence between flowpaths and waterbodies -- we could even drop waterbodies from the mix all together if hydrologic routing attributes can be attached to flowpaths.
As we go forward, we will want to use flowpaths as a way to handle hydrologic locations along waterbodies providing the tie points between the linear catchment-realization and hydrodynamic model representations of waterbodies.

Need to create a diagram that clarifies how this works.


Site down

+1 lots of links around the web are dead atm cuz of this

You can use this mirror temporarily https://jsperf.app/

jsperf.com URLs are mirrored at the same path, e.g: https://jsperf.com/negative-modulo/2

No, they aren't. This website doesn't have a full jsperf's database.

Still sit down

Still down!

Still down

Down as of 2024

Guys, I think that the project is clearly abandoned.

Guys, I think that the project is clearly abandoned.
The domain expires later this year. Someone might want to buy it to prevent malicious use.

The expiration date is listed as 2024-07-06 10:24:19 UTC according to lookup.icann.org but I'm not sure if it's in YYYY-MM-DD or YYYY-DD-MM

Seems like it was extended
Registry Expiration: 2025-07-06 10:24:19 UTC
But the site is still down

If it is extended... then why is it not working?
Rhetorical question..


Select all on hover selects stuff from global search

Issue Type: Bug
Trying to do https://github.com/Microsoft/vscode/issues/63296#issuecomment-439553039

Open global search viewlet and execute search
Put cursor inside editor in place where hover is available
editor.action.showHover
editor.action.selectAll
🐛 The text from search results and tab titles and even some opened editor text is selected

VS Code version: Code 1.30.0 (c6e592b2b5770e40a98cb9c2715a8ef89aec3d74, 2018-12-11T22:29:11.253Z)
OS version: Windows_NT x64 10.0.17763

I see this, but strangely, I can only get "select all" in the hover to work at all on Windows as described in https://github.com/Microsoft/vscode/issues/63296#issuecomment-439820773.
On Mac I see

cmd+K cmd+I to show the hover and focus it
cmd+A to select all the hover content
But the editor text is selected instead, and hover text is not selected.

Any idea why @alexandrudima? I can debug if you know how the keypress is supposed to be intercepted.

@roblourens The weird behaviour that you see on macOS shares the same root cause as #35225 i.e. I think cmd+A is dispatched by the Electron menu and then we invoke editor.action.selectAll even if textInputFocus is not defined in the context. Since we just merged #64228 you should not see the weirdness anymore, i.e. cmd+A will be dispatched by our keybindings service even on macOS... But I haven't really tested...
AFAICT on Windows the ctrl+A falls back to execute what ctrl+A would execute in a browser (i.e. nobody calls preventDefault). That ends up selecting anything that is selectable, including inputs. I am thinking @usernamehw wishes that ctrl+A when the focus is in the hover would select only the hover contents. That would need to be implemented, i.e. a feature request for the editor hover.

Yeah, now cmd+A on mac does nothing in this case, which I guess is correct.
I think your explanation makes sense, I'll assign this to you for

That would need to be implemented, i.e. a feature request for the editor hover.


Update name of section of the location of the examples in doc

Description of the problem
All the examples in the documentation had a section called  "Location of the examples"  with the exception of three cases.
Description of the solution
The section was renamed for all the examples to"Location of the files used in this example".
Comments
We still need to agree on the capitalization of the titles in the documentation... as all the rpt examples and two examples in the incompressible flow examples (the 3D mixer and ribbon mixer) have all the titles capitalized. We could agree on something and correct it in this PR).

The titles were updated according to our talk!


Admin Area doesn't exist

I tried accessing the admin area with the /bb-admin and index.php?_url=/bb-admin but both don't work. (gives me a 404 error). Checked the files and no such file named as "bb-admin" was found. Did I make a mistake? How do you guys access your admin area?

i have been having the same issue, i just found a comment that said to change 'sef_urls' => false, on bb-config.php
and it worked for me, i am using apache

Fixed. Just waited for a few hours and it resolved itself. I'm not sure what happened really...


Cannot deploy, at least, marsha with eugene customer in development

Bug Report
Expected behavior/code
When I bootstrap the marsha application with eugene customer in development environment it should not fail.
Actual Behavior
It fails because secrets are not valid in marsha's vault.
I think the line 19 of file apps/marsha/templates/app/secret.yml.j2 should be:
DJANGO_SENTRY_DSN: "{{ MARSHA_VAULT.DJANGO_SENTRY_DSN | default('') | b64encode }}"

I also think that every django applications using sentry can have this issue.
Steps to Reproduce

./bin/bootstrap -e "apps_filter=marsha"

Environment

Arnold version: master
Platform: linux

Yeah it should be fixed as we did for Richie, see https://github.com/openfun/arnold/blob/master/apps/richie/templates/app/secret.yml.j2#L11


Provide an endpoint, for Rivet, to restart devnet in forking mode

We would like to fork devnet from Starknet Rivet.
The idea is to send an RPC request to devnet, with an URL and optional block number, so that the devnet gets restarted - forked from this URL (and optional block)!

Hi @ivpavici
I am a Smart contract and a fullstack developer.
Could you kindly assign me to work on this issue, please?

Duplicate of #504


Thanos Query stop responding if not queried for some time

Thanos, Prometheus and Golang version used
Docker tags:
thanos:
  version: v0.2.1
prometheus:
  version: v2.5.0

What happened
When thanos-query is not used for some time, it stops answering when we try to query again and only work after are restart.
We saw that when we shut our persistent grafana dashboard (shown on screens on the office), now every time we go to grafana or to the thanos-query interface, the queries hang up forever until we restart thanos-query.
CPU usage on all the thanos relarted processes are low so it doesn't look like it's doing anything.
All the stores are up in thanos-query dashboard but all queries are failing (even up).
After restarting thanos query everything works fine for a few hours (I don't know the exact time)
What you expected to happen
Query working fine
How to reproduce it (as minimally and precisely as possible):
Don't do queries for a few hours, then try to query
Full logs to relevant components
Nothing in the logs except context cancelled because the HTTP queries are timing out on Grafana
Anything else we need to know
Environment:

OS: Docker 18.09.0 on Centos 7
Kernel (e.g. uname -a): Linux gc-euw1-prometheus-central-1 3.10.0-862.14.4.el7.x86_64 #1 SMP Wed Sep 26 15:12:11 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Others:

There you have the related salt state to deploy query and store :
Make sure Thanos Query is running in Docker:
  docker_container.running:
    - name: thanos-query
    - image: improbable/thanos:{{ pillar["thanos"]["version"] }}
    - user: 4002
    - restart_policy: always
    - network_mode: host
    - command: >
        query
        --cluster.peers store.thanos.internal.xxx.net:10903
        --query.replica-label replica
        --cluster.address <IP_ADDRESS>:10906
        --cluster.advertise-address {{ grains["ip4_interfaces"]["eth0"][0] }}:10906
        --grpc-address <IP_ADDRESS>:10907
        --grpc-advertise-address {{ grains["ip4_interfaces"]["eth0"][0] }}:10907
        --http-address <IP_ADDRESS>:10908
        --http-advertise-address {{ grains["ip4_interfaces"]["eth0"][0] }}:10908
    - binds:
      - "/var/data/thanos:/var/data/thanos:Z"
      - "/etc/monitoring/prometheus:/etc/prometheus:Z"
    - environment:
      - GOOGLE_APPLICATION_CREDENTIALS: /etc/prometheus/gcloud.json

Make sure Thanos Store is running in Docker:
  docker_container.running:
    - name: thanos-store
    - image: improbable/thanos:{{ pillar["thanos"]["version"] }}
    - user: 4002
    - restart_policy: always
    - network_mode: host
    - command: >
        store
        --data-dir /var/data/thanos/store
        --cluster.peers query.thanos.internal.xxx.net:10900
        --objstore.config-file /etc/thanos/bucket.yml
        --cluster.address <IP_ADDRESS>:10903
        --cluster.advertise-address {{ grains["ip4_interfaces"]["eth0"][0] }}:10903
        --grpc-address <IP_ADDRESS>:10904
        --grpc-advertise-address {{ grains["ip4_interfaces"]["eth0"][0] }}:10904
        --http-address <IP_ADDRESS>:10905
    - binds:
      - "/var/data/thanos:/var/data/thanos:Z"
      - "/etc/monitoring/prometheus:/etc/prometheus:Z"
      - "/etc/monitoring/thanos:/etc/thanos:Z"
    - environment:
      - GOOGLE_APPLICATION_CREDENTIALS: /etc/prometheus/gcloud.json

## Then on remote nodes containing Prometheus instances
Make sure Thanos Sidecar is running in Docker:
  docker_container.running:
    - name: thanos-sidecar
    - image: improbable/thanos:{{ pillar["thanos"]["version"] }}
    - user: 4000
    - restart_policy: always
    - network_mode: host
    - command: >
        sidecar
        --prometheus.url http://localhost:9090
        --tsdb.path /prometheus
        --objstore.config-file /etc/thanos/bucket.yml
        --cluster.peers query.thanos.internal.xxx.net:10906
        --cluster.peers store.thanos.internal.xxx.net:10903
        --cluster.address <IP_ADDRESS>:10900
        --cluster.advertise-address {{ grains["ip4_interfaces"]["eth0"][0] }}:10900
        --grpc-address <IP_ADDRESS>:10901
        --grpc-advertise-address {{ grains["ip4_interfaces"]["eth0"][0] }}:10901
        --http-address <IP_ADDRESS>:10902
    - environment:
      - GOOGLE_APPLICATION_CREDENTIALS: /etc/prometheus/gcloud.json
    - binds:
      - "/etc/monitoring/prometheus:/etc/prometheus:Z"
      - "/etc/monitoring/thanos:/etc/thanos:Z"
      - "/var/data/prometheus:/prometheus:Z"

It happened right now, on the stores panel everything is green, health checks are still responding correctly but I can't for example run a up query, hanging forever on it.

Intesting. No immdiate clue - we cannot repro it.
So what is really weird in your setup, is that you have 5 replica HA for Prometheus.. Does it mean all 5 instances scrape the same data? Because that's for query-replica flag in Thanos querier is for. It might work despite that just accidently (because all internal metric labels are similar), but I think you are doing something you did not intent to do.
Nevertheless what might happen now, is that one of those StoreAPI might hang for some reason? Potentially store gateway? One hanging leaf can cause Thanos query to timeout after some time.
I would suggest:

checking logs on leafs (for sure for <IP_ADDRESS> which is your store gateway)
Turning off one by one leafs from gossip, (it's easier when you use DNS than gossip) and try Thanos Querier against on of those leafs only to detect which causes problem. Again, I think you might get some problem with store gateway acessing object store or something?

Each instance monitor their own system, they don't share metrics data (Except to monitor each other monitoring system (monitoring each other prometheus, alertmanager, sidecars, etc.)
Should I remove the replica global label from my configuration ?
I've checked the store logs but there is nothing.
What I see is that for example queries like up that need all the leafs are hanging forever but targetting some leafs like up{replica="central"} works fine and it looks like one (bcn) is not working.
When taking a look at this leaf log, there's nothing shown failing recently (Just the classic upload new block).
When restarting this leaf (And not the thanos query like before) it works, but I suppose this will happen again in a few hours (as it was restarted before this ticket as I updated the version from master-2018-11-12-9cec837 to v0.2.1 to try to solve the issue)

Yes, they are definitely not replicas then. They are shards (: I would not remove replica label as then you external labels won't be unique (they have to). Just add something that suits your functional shard like cluster or shard (:
Not sure if that is the reason for your weirdiness query timeouts, but for a try.
Have you try turning of some leaf then? when Querier hangs, maybe worth to turn off them one by one.
Also in case on hanging worth to check Thanos Querier metrics.
Maybe concurrent queries are full for some reason for you?
# HELP prometheus_engine_queries The current number of queries being executed or waiting.
# TYPE prometheus_engine_queries gauge
prometheus_engine_queries 4
# HELP prometheus_engine_queries_concurrent_max The max number of concurrent queries.
# TYPE prometheus_engine_queries_concurrent_max gauge
prometheus_engine_queries_concurrent_max 100

``

When I shutdown the only one that had the issue (bcn) and wait for it to appear red in the store part, queries starts to work again, then when I start it again it keeps working (for a few hours I suppose)
The query limit is 20 everywhere but I can see that sometime the thanos-query reach more than 60 concurrent queries, I think this is when I try to open Grafana and that it gets hanging forever because of the issue.
If I change the label (I suppose it need to be changed everywhere at the same time), that won't affect the ability to read the previous metrics ? Any consequence ?

The query limit is 20 everywhere but I can see that sometime the thanos-query reach more than 60 concurrent queries, I think this is when I try to open Grafana and that it gets hanging forever because of the issue.

Doesn't this sounds like your issue here? Can you try to change max-concurrent to 100 e.g? BTW what is running on <IP_ADDRESS>:10904?
Well, the result will have different labels, otherwise for your case it should be fine (:

<IP_ADDRESS>:10904 is the Thanos store, I will try next week to change the limit to 100, but I don't think that as this would only affect Grafana and not single queries from the query UI ?

I think I might've run into the same issue. My Thanos query instance stopped responding seemingly randomly. There are no error logs or any other indicators that I can find that something went wrong. The logs for Thanos Query are simply empty between the time it stopped responding and the time I restarted the container:
level=warn ts=2019-05-22T21:48:00.894943163Z caller=proxy.go:346 err="failed to receive any data from Addr: thanos_sidecar:10901 Labels: [{replica 1 {} [] 0} {team occ {} [] 0}] Mint:<PHONE_NUMBER>000 Maxt:<PHONE_NUMBER>854775807: context canceled" msg="returning partial response"
level=info ts=2019-05-23T02:25:36.52785599Z caller=main.go:193 msg="caught signal. Exiting." signal=terminated

On the Thanos Query HTTP page, the Stores all showed as healthy. And restarting only Thanos Query resolved the issue so I don't think it's the sidecars or the Thanos Store node.
Thanos Query just stopped responding to requests, but still reported itself as healthy. It was still exposing its metrics, so it wasn't frozen. Queries just timed out when run in the web UI (or Grafana)

After further research, it looks like I also hit the 20 concurrent queries limit. It spiked to over 20 and then came back down to exactly 20 and stayed there. Is there a reason why queries would be stuck in the queue and not getting cleared out?

I've hit this case too with v0.4.0 and have collected all pprof profiles from Thanos Querier.
I will assign this issue to myself and plan to work on this soon.

Ok turns out I was running image: improbable/thanos:master-2019-03-26-7465db9, but the same issue should be hapenning in all new versions.

Digging thru goroutine dump I found that many goroutines wait forever on wg.Wait() call:
goroutine 28662879 [semacquire, 2958 minutes]:
sync.runtime_Semacquire(0xc0140a4344)
	/usr/local/go/src/runtime/sema.go:56 +0x39
sync.(*WaitGroup).Wait(0xc0140a4344)
	/usr/local/go/src/sync/waitgroup.go:130 +0x65
github.com/improbable-eng/thanos/pkg/store.(*ProxyStore).Series.func1.1(0xc0140a4344, 0xc000736ae0)
	/go/src/github.com/improbable-eng/thanos/pkg/store/proxy.go:144 +0x2b
github.com/improbable-eng/thanos/pkg/store.(*ProxyStore).Series.func1(0x13cdd60, 0xc0003338e0)
	/go/src/github.com/improbable-eng/thanos/pkg/store/proxy.go:198 +0x74a
golang.org/x/sync/errgroup.(*Group).Go.func1(0xc000f0ddd0, 0xc004a030e0)
	/go/pkg/mod/golang.org/x/sync@v0.0.0-20181221193216-37e7f081c4d4/errgroup/errgroup.go:57 +0x57
created by golang.org/x/sync/errgroup.(*Group).Go
	/go/pkg/mod/golang.org/x/sync@v0.0.0-20181221193216-37e7f081c4d4/errgroup/errgroup.go:54 +0x66

goroutine 159624 [semacquire, 3880 minutes]:
sync.runtime_Semacquire(0xc001b952a8)
	/usr/local/go/src/runtime/sema.go:56 +0x39
sync.(*WaitGroup).Wait(0xc001b952a0)
	/usr/local/go/src/sync/waitgroup.go:130 +0x65
github.com/improbable-eng/thanos/pkg/store.(*ProxyStore).Series.func1.1(0xc001b952a0, 0xc000e66790)
	/go/src/github.com/improbable-eng/thanos/pkg/store/proxy.go:144 +0x2b
github.com/improbable-eng/thanos/pkg/store.(*ProxyStore).Series.func1(0x13cdd60, 0xc000dd9c20)
	/go/src/github.com/improbable-eng/thanos/pkg/store/proxy.go:171 +0x13fb
golang.org/x/sync/errgroup.(*Group).Go.func1(0xc0029c5980, 0xc000c854f0)
	/go/pkg/mod/golang.org/x/sync@v0.0.0-20181221193216-37e7f081c4d4/errgroup/errgroup.go:57 +0x57
created by golang.org/x/sync/errgroup.(*Group).Go
	/go/pkg/mod/golang.org/x/sync@v0.0.0-20181221193216-37e7f081c4d4/errgroup/errgroup.go:54 +0x66

goroutine 28663415 [semacquire, 2958 minutes]:
sync.runtime_Semacquire(0xc002c4f3f8)
	/usr/local/go/src/runtime/sema.go:56 +0x39
sync.(*WaitGroup).Wait(0xc002c4f3f0)
	/usr/local/go/src/sync/waitgroup.go:130 +0x65
github.com/improbable-eng/thanos/pkg/store.(*ProxyStore).Series.func1.1(0xc002c4f3f0, 0xc00239ac00)
	/go/src/github.com/improbable-eng/thanos/pkg/store/proxy.go:144 +0x2b
github.com/improbable-eng/thanos/pkg/store.(*ProxyStore).Series.func1(0x13cdd60, 0xc0055b9320)
	/go/src/github.com/improbable-eng/thanos/pkg/store/proxy.go:198 +0x74a
golang.org/x/sync/errgroup.(*Group).Go.func1(0xc000969860, 0xc001a46410)
	/go/pkg/mod/golang.org/x/sync@v0.0.0-20181221193216-37e7f081c4d4/errgroup/errgroup.go:57 +0x57
created by golang.org/x/sync/errgroup.(*Group).Go
	/go/pkg/mod/golang.org/x/sync@v0.0.0-20181221193216-37e7f081c4d4/errgroup/errgroup.go:54 +0x66

goroutine 159718 [semacquire, 3880 minutes]:
sync.runtime_Semacquire(0xc001e2ddf8)
	/usr/local/go/src/runtime/sema.go:56 +0x39
sync.(*WaitGroup).Wait(0xc001e2ddf0)
	/usr/local/go/src/sync/waitgroup.go:130 +0x65
github.com/improbable-eng/thanos/pkg/store.(*ProxyStore).Series.func1.1(0xc001e2ddf0, 0xc000f18040)
	/go/src/github.com/improbable-eng/thanos/pkg/store/proxy.go:144 +0x2b
github.com/improbable-eng/thanos/pkg/store.(*ProxyStore).Series.func1(0x13cdd60, 0xc000b4e800)
	/go/src/github.com/improbable-eng/thanos/pkg/store/proxy.go:171 +0x13fb
golang.org/x/sync/errgroup.(*Group).Go.func1(0xc000b741b0, 0xc002655590)
	/go/pkg/mod/golang.org/x/sync@v0.0.0-20181221193216-37e7f081c4d4/errgroup/errgroup.go:57 +0x57
created by golang.org/x/sync/errgroup.(*Group).Go
	/go/pkg/mod/golang.org/x/sync@v0.0.0-20181221193216-37e7f081c4d4/errgroup/errgroup.go:54 +0x66

Another good question is what did thanos store API call goroutines were doing, because they haven't returned data in 3880s ~ 1h

goroutine 28662020 [IO wait, 2958 minutes]:
internal/poll.runtime_pollWait(0x7fa6712c03a8, 0x72, 0xffffffffffffffff)
	/usr/local/go/src/runtime/netpoll.go:182 +0x56
internal/poll.(*pollDesc).wait(0xc000738898, 0x72, 0x0, 0x1, 0xffffffffffffffff)
	/usr/local/go/src/internal/poll/fd_poll_runtime.go:87 +0x9b
internal/poll.(*pollDesc).waitRead(...)
	/usr/local/go/src/internal/poll/fd_poll_runtime.go:92
internal/poll.(*FD).Read(0xc000738880, 0xc000be8131, 0x1, 0x1, 0x0, 0x0, 0x0)
	/usr/local/go/src/internal/poll/fd_unix.go:169 +0x19b
net.(*netFD).Read(0xc000738880, 0xc000be8131, 0x1, 0x1, 0xc00051b7d8, 0xc00462b768, 0x4715cd)
	/usr/local/go/src/net/fd_unix.go:202 +0x4f
net.(*conn).Read(0xc00bdaa8d8, 0xc000be8131, 0x1, 0x1, 0x0, 0x0, 0x0)
	/usr/local/go/src/net/net.go:177 +0x69
net/http.(*connReader).backgroundRead(0xc000be8120)
	/usr/local/go/src/net/http/server.go:677 +0x58
created by net/http.(*connReader).startBackgroundRead
	/usr/local/go/src/net/http/server.go:673 +0xca

goroutine 28560291 [chan receive, 2958 minutes]:
github.com/improbable-eng/thanos/pkg/store.(*ProxyStore).Series(0xc000340960, 0xc0002e38f0, 0x13fcea0, 0xc00093f7c0, 0x1, 0x5)
	/go/src/github.com/improbable-eng/thanos/pkg/store/proxy.go:201 +0x28c
github.com/improbable-eng/thanos/pkg/query.(*querier).Select(0xc000846600, 0xc002b15c50, 0xc00bcb8180, 0x3, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/go/src/github.com/improbable-eng/thanos/pkg/query/querier.go:184 +0x29e
github.com/prometheus/prometheus/promql.(*Engine).populateSeries.func2(0x13cdec0, 0xc015b06540, 0xc0012f6b00, 0x3, 0x4, 0xc000846600, 0xc0003b98c0)
	/go/pkg/mod/github.com/prometheus/prometheus@v0.0.0-20190118110214-3bd41cc92c78/promql/engine.go:585 +0x884
github.com/prometheus/prometheus/promql.inspector.Visit(0xc0012f6ac0, 0x13cdec0, 0xc015b06540, 0xc0012f6b00, 0x3, 0x4, 0x10a23e0, 0x13cdec0, 0xc00bcb8340, 0x20)
	/go/pkg/mod/github.com/prometheus/prometheus@v0.0.0-20190118110214-3bd41cc92c78/promql/ast.go:309 +0x5c
github.com/prometheus/prometheus/promql.Walk(0x13cfee0, 0xc0012f6ac0, 0x13cdec0, 0xc015b06540, 0xc0012f6b00, 0x3, 0x4, 0x4, 0x0)
	/go/pkg/mod/github.com/prometheus/prometheus@v0.0.0-20190118110214-3bd41cc92c78/promql/ast.go:245 +0x8a
github.com/prometheus/prometheus/promql.Walk(0x13cfee0, 0xc0012f6ac0, 0x13cfec0, 0xc00bcb8360, 0xc0012f6b00, 0x3, 0x4, 0x2, 0x0)
	/go/pkg/mod/github.com/prometheus/prometheus@v0.0.0-20190118110214-3bd41cc92c78/promql/ast.go:258 +0x2bf
github.com/prometheus/prometheus/promql.Walk(0x13cfee0, 0xc0012f6ac0, 0x13cde80, 0xc00bcb81a0, 0xc00bcb8340, 0x2, 0x2, 0x1, 0x0)
	/go/pkg/mod/github.com/prometheus/prometheus@v0.0.0-20190118110214-3bd41cc92c78/promql/ast.go:276 +0xa9c
github.com/prometheus/prometheus/promql.Walk(0x13cfee0, 0xc0012f6ac0, 0x13cde60, 0xc0012f6980, 0xc000f18700, 0x1, 0x1, 0x0, 0x0)
	/go/pkg/mod/github.com/prometheus/prometheus@v0.0.0-20190118110214-3bd41cc92c78/promql/ast.go:268 +0x7e4
github.com/prometheus/prometheus/promql.Inspect(...)
	/go/pkg/mod/github.com/prometheus/prometheus@v0.0.0-20190118110214-3bd41cc92c78/promql/ast.go:320
github.com/prometheus/prometheus/promql.(*Engine).populateSeries(0xc0003b98c0, 0x13ebfc0, 0xc002b15b30, 0x13cdb20, 0xc00093f540, 0xc00093f5e0, 0x1, 0xc002b15b60, 0x13ebfc0, 0xc002b15b30, ...)
	/go/pkg/mod/github.com/prometheus/prometheus@v0.0.0-20190118110214-3bd41cc92c78/promql/engine.go:547 +0x3dc
github.com/prometheus/prometheus/promql.(*Engine).execEvalStmt(0xc0003b98c0, 0x13ebfc0, 0xc002b15ad0, 0xc015b065a0, 0xc00093f5e0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/go/pkg/mod/github.com/prometheus/prometheus@v0.0.0-20190118110214-3bd41cc92c78/promql/engine.go:409 +0x171
github.com/prometheus/prometheus/promql.(*Engine).exec(0xc0003b98c0, 0x13ebfc0, 0xc002b15ad0, 0xc015b065a0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/go/pkg/mod/github.com/prometheus/prometheus@v0.0.0-20190118110214-3bd41cc92c78/promql/engine.go:390 +0x567
github.com/prometheus/prometheus/promql.(*query).Exec(0xc015b065a0, 0x13ebfc0, 0xc002b15830, 0xc001749b20)
	/go/pkg/mod/github.com/prometheus/prometheus@v0.0.0-20190118110214-3bd41cc92c78/promql/engine.go:178 +0x94
github.com/improbable-eng/thanos/pkg/query/api.(*API).query(0xc0003402d0, 0xc00086fa00, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
	/go/src/github.com/improbable-eng/thanos/pkg/query/api/v1.go:298 +0x4d9
github.com/improbable-eng/thanos/pkg/query/api.(*API).Register.func1.1(0x13e7b00, 0xc015b063c0, 0xc00086fa00)
	/go/src/github.com/improbable-eng/thanos/pkg/query/api/v1.go:157 +0x55
net/http.HandlerFunc.ServeHTTP(0xc0004d4320, 0x13e7b00, 0xc015b063c0, 0xc00086fa00)
	/usr/local/go/src/net/http/server.go:1995 +0x44
github.com/NYTimes/gziphandler.GzipHandlerWithOpts.func1.1(0x13e63c0, 0xc0005222f8, 0xc00086fa00)
	/go/pkg/mod/github.com/!n!y!times/gziphandler@v1.0.1/gzip.go:287 +0x210
net/http.HandlerFunc.ServeHTTP(0xc0000a5590, 0x13e63c0, 0xc0005222f8, 0xc00086fa00)
	/usr/local/go/src/net/http/server.go:1995 +0x44
github.com/improbable-eng/thanos/pkg/tracing.HTTPMiddleware.func1(0x13e63c0, 0xc0005222f8, 0xc00086f900)
	/go/src/github.com/improbable-eng/thanos/pkg/tracing/http.go:37 +0x511
net/http.HandlerFunc.ServeHTTP(0xc000340780, 0x13e63c0, 0xc0005222f8, 0xc00086f900)
	/usr/local/go/src/net/http/server.go:1995 +0x44
github.com/prometheus/client_golang/prometheus.InstrumentHandlerFuncWithOpts.func1(0x13e7980, 0xc00130c0e0, 0xc00086f900)
	/go/pkg/mod/github.com/prometheus/client_golang@v0.9.2/prometheus/http.go:260 +0x232
github.com/prometheus/common/route.(*Router).handle.func1(0x13e7980, 0xc00130c0e0, 0xc00086f800, 0x0, 0x0, 0x0)
	/go/pkg/mod/github.com/prometheus/common@v0.0.0-20181218105931-67670fe90761/route/route.go:60 +0x26e
github.com/julienschmidt/httprouter.(*Router).ServeHTTP(0xc0003b9950, 0x13e7980, 0xc00130c0e0, 0xc00086f800)
	/go/pkg/mod/github.com/julienschmidt/httprouter@v1.1.0/router.go:299 +0x6d1
github.com/prometheus/common/route.(*Router).ServeHTTP(0xc0003d9100, 0x13e7980, 0xc00130c0e0, 0xc00086f800)
	/go/pkg/mod/github.com/prometheus/common@v0.0.0-20181218105931-67670fe90761/route/route.go:98 +0x4c
net/http.(*ServeMux).ServeHTTP(0xc000152940, 0x13e7980, 0xc00130c0e0, 0xc00086f800)
	/usr/local/go/src/net/http/server.go:2375 +0x1d6
net/http.serverHandler.ServeHTTP(0xc00013e000, 0x13e7980, 0xc00130c0e0, 0xc00086f800)
	/usr/local/go/src/net/http/server.go:2774 +0xa8
net/http.(*conn).serve(0xc00b854d20, 0x13ebf00, 0xc001a62a80)
	/usr/local/go/src/net/http/server.go:1878 +0x851
created by net/http.(*Server).Serve
	/usr/local/go/src/net/http/server.go:2884 +0x2f4

goroutine 68762076 [chan receive, 1164 minutes]:
github.com/improbable-eng/thanos/pkg/store.(*ProxyStore).Series(0xc000340960, 0xc002208620, 0x13fcea0, 0xc011ad22d0, 0x2, 0x0)
	/go/src/github.com/improbable-eng/thanos/pkg/store/proxy.go:201 +0x28c
github.com/improbable-eng/thanos/pkg/query.(*querier).Select(0xc00b16e900, 0xc000da24e0, 0xc00051c6e0, 0x2, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/go/src/github.com/improbable-eng/thanos/pkg/query/querier.go:184 +0x29e
github.com/prometheus/prometheus/promql.(*Engine).populateSeries.func2(0x13cdec0, 0xc000ac5aa0, 0xc000160fc0, 0x3, 0x4, 0xc00b16e900, 0xc0003b98c0)
	/go/pkg/mod/github.com/prometheus/prometheus@v0.0.0-20190118110214-3bd41cc92c78/promql/engine.go:585 +0x884
github.com/prometheus/prometheus/promql.inspector.Visit(0xc000160f80, 0x13cdec0, 0xc000ac5aa0, 0xc000160fc0, 0x3, 0x4, 0x10a23e0, 0x13cdec0, 0xc0016f0d60, 0x20)
	/go/pkg/mod/github.com/prometheus/prometheus@v0.0.0-20190118110214-3bd41cc92c78/promql/ast.go:309 +0x5c
github.com/prometheus/prometheus/promql.Walk(0x13cfee0, 0xc000160f80, 0x13cdec0, 0xc000ac5aa0, 0xc000160fc0, 0x3, 0x4, 0x4, 0x0)
	/go/pkg/mod/github.com/prometheus/prometheus@v0.0.0-20190118110214-3bd41cc92c78/promql/ast.go:245 +0x8a
github.com/prometheus/prometheus/promql.Walk(0x13cfee0, 0xc000160f80, 0x13cfec0, 0xc0016f0d80, 0xc000160fc0, 0x3, 0x4, 0x2, 0x0)
	/go/pkg/mod/github.com/prometheus/prometheus@v0.0.0-20190118110214-3bd41cc92c78/promql/ast.go:258 +0x2bf
github.com/prometheus/prometheus/promql.Walk(0x13cfee0, 0xc000160f80, 0x13cde80, 0xc0016f0bc0, 0xc0016f0d60, 0x2, 0x2, 0x1, 0x0)
	/go/pkg/mod/github.com/prometheus/prometheus@v0.0.0-20190118110214-3bd41cc92c78/promql/ast.go:276 +0xa9c
github.com/prometheus/prometheus/promql.Walk(0x13cfee0, 0xc000160f80, 0x13cde40, 0xc011ad20a0, 0xc00051c950, 0x1, 0x1, 0x0, 0x0)
	/go/pkg/mod/github.com/prometheus/prometheus@v0.0.0-20190118110214-3bd41cc92c78/promql/ast.go:263 +0x5ac
github.com/prometheus/prometheus/promql.Inspect(...)
	/go/pkg/mod/github.com/prometheus/prometheus@v0.0.0-20190118110214-3bd41cc92c78/promql/ast.go:320
github.com/prometheus/prometheus/promql.(*Engine).populateSeries(0xc0003b98c0, 0x13ebfc0, 0xc000da23c0, 0x13cdb20, 0xc011ad2000, 0xc011ad20f0, 0x1, 0xc000da23f0, 0x13ebfc0, 0xc000da23c0, ...)
	/go/pkg/mod/github.com/prometheus/prometheus@v0.0.0-20190118110214-3bd41cc92c78/promql/engine.go:547 +0x3dc
github.com/prometheus/prometheus/promql.(*Engine).execEvalStmt(0xc0003b98c0, 0x13ebfc0, 0xc000da2360, 0xc000ac5b00, 0xc011ad20f0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/go/pkg/mod/github.com/prometheus/prometheus@v0.0.0-20190118110214-3bd41cc92c78/promql/engine.go:409 +0x171
github.com/prometheus/prometheus/promql.(*Engine).exec(0xc0003b98c0, 0x13ebfc0, 0xc000da2360, 0xc000ac5b00, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/go/pkg/mod/github.com/prometheus/prometheus@v0.0.0-20190118110214-3bd41cc92c78/promql/engine.go:390 +0x567
github.com/prometheus/prometheus/promql.(*query).Exec(0xc000ac5b00, 0x13ebfc0, 0xc0035dfe90, 0xc0008b9da0)
	/go/pkg/mod/github.com/prometheus/prometheus@v0.0.0-20190118110214-3bd41cc92c78/promql/engine.go:178 +0x94
github.com/improbable-eng/thanos/pkg/query/api.(*API).queryRange(0xc0003402d0, 0xc011ad0000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
	/go/src/github.com/improbable-eng/thanos/pkg/query/api/v1.go:402 +0xb1e
github.com/improbable-eng/thanos/pkg/query/api.(*API).Register.func1.1(0x13e7b00, 0xc000ac58c0, 0xc011ad0000)
	/go/src/github.com/improbable-eng/thanos/pkg/query/api/v1.go:157 +0x55
net/http.HandlerFunc.ServeHTTP(0xc0004d4790, 0x13e7b00, 0xc000ac58c0, 0xc011ad0000)
	/usr/local/go/src/net/http/server.go:1995 +0x44
github.com/NYTimes/gziphandler.GzipHandlerWithOpts.func1.1(0x13e63c0, 0xc00ef3b650, 0xc011ad0000)
	/go/pkg/mod/github.com/!n!y!times/gziphandler@v1.0.1/gzip.go:287 +0x210
net/http.HandlerFunc.ServeHTTP(0xc00013b4a0, 0x13e63c0, 0xc00ef3b650, 0xc011ad0000)
	/usr/local/go/src/net/http/server.go:1995 +0x44
github.com/improbable-eng/thanos/pkg/tracing.HTTPMiddleware.func1(0x13e63c0, 0xc00ef3b650, 0xc00455df00)
	/go/src/github.com/improbable-eng/thanos/pkg/tracing/http.go:37 +0x511
net/http.HandlerFunc.ServeHTTP(0xc000340d70, 0x13e63c0, 0xc00ef3b650, 0xc00455df00)
	/usr/local/go/src/net/http/server.go:1995 +0x44
github.com/prometheus/client_golang/prometheus.InstrumentHandlerFuncWithOpts.func1(0x13e7980, 0xc000a36620, 0xc00455df00)
	/go/pkg/mod/github.com/prometheus/client_golang@v0.9.2/prometheus/http.go:260 +0x232
github.com/prometheus/common/route.(*Router).handle.func1(0x13e7980, 0xc000a36620, 0xc00455de00, 0x0, 0x0, 0x0)
	/go/pkg/mod/github.com/prometheus/common@v0.0.0-20181218105931-67670fe90761/route/route.go:60 +0x26e
github.com/julienschmidt/httprouter.(*Router).ServeHTTP(0xc0003b9950, 0x13e7980, 0xc000a36620, 0xc00455de00)
	/go/pkg/mod/github.com/julienschmidt/httprouter@v1.1.0/router.go:299 +0x6d1
github.com/prometheus/common/route.(*Router).ServeHTTP(0xc0003d9100, 0x13e7980, 0xc000a36620, 0xc00455de00)
	/go/pkg/mod/github.com/prometheus/common@v0.0.0-20181218105931-67670fe90761/route/route.go:98 +0x4c
net/http.(*ServeMux).ServeHTTP(0xc000152940, 0x13e7980, 0xc000a36620, 0xc00455de00)
	/usr/local/go/src/net/http/server.go:2375 +0x1d6
net/http.serverHandler.ServeHTTP(0xc00013e000, 0x13e7980, 0xc000a36620, 0xc00455de00)
	/usr/local/go/src/net/http/server.go:2774 +0xa8
net/http.(*conn).serve(0xc002552aa0, 0x13ebf00, 0xc000160d00)
	/usr/local/go/src/net/http/server.go:1878 +0x851
created by net/http.(*Server).Serve
	/usr/local/go/src/net/http/server.go:2884 +0x2f4

Ok this data is a bit too confusing, as I am running older version, which didn't have fix for Thanos query

We decided we need to rewrite that part to make it simpler.

Looks like your findings are consistent with what I'm seeing, too. I currently have 3 queries stuck in the queue (based on prometheus_engine_queries metric), with similar goroutine traces:
ps - thanks for your work on this! Let me know if there's anything that I can help with :)
goroutine 7346097 [semacquire, 1282 minutes]:
sync.runtime_Semacquire(0xc000e4e0b8)
	/usr/local/go/src/runtime/sema.go:56 +0x39
sync.(*WaitGroup).Wait(0xc000e4e0b0)
	/usr/local/go/src/sync/waitgroup.go:130 +0x65
github.com/improbable-eng/thanos/pkg/store.(*ProxyStore).Series.func1.1(0xc000e4e0b0, 0xc000cf42a0)
	/go/src/github.com/improbable-eng/thanos/pkg/store/proxy.go:166 +0x2b
github.com/improbable-eng/thanos/pkg/store.(*ProxyStore).Series.func1(0x0, 0x0)
	/go/src/github.com/improbable-eng/thanos/pkg/store/proxy.go:220 +0x74a
golang.org/x/sync/errgroup.(*Group).Go.func1(0xc00072e1e0, 0xc00042a550)
	/go/pkg/mod/golang.org/x/sync@v0.0.0-20181221193216-37e7f081c4d4/errgroup/errgroup.go:57 +0x57
created by golang.org/x/sync/errgroup.(*Group).Go
	/go/pkg/mod/golang.org/x/sync@v0.0.0-20181221193216-37e7f081c4d4/errgroup/errgroup.go:54 +0x66

goroutine 8193383 [semacquire, 886 minutes]:
sync.runtime_Semacquire(0xc00093e708)
	/usr/local/go/src/runtime/sema.go:56 +0x39
sync.(*WaitGroup).Wait(0xc00093e700)
	/usr/local/go/src/sync/waitgroup.go:130 +0x65
github.com/improbable-eng/thanos/pkg/store.(*ProxyStore).Series.func1.1(0xc00093e700, 0xc0009ad980)
	/go/src/github.com/improbable-eng/thanos/pkg/store/proxy.go:166 +0x2b
github.com/improbable-eng/thanos/pkg/store.(*ProxyStore).Series.func1(0x0, 0x0)
	/go/src/github.com/improbable-eng/thanos/pkg/store/proxy.go:220 +0x74a
golang.org/x/sync/errgroup.(*Group).Go.func1(0xc000805c50, 0xc000842460)
	/go/pkg/mod/golang.org/x/sync@v0.0.0-20181221193216-37e7f081c4d4/errgroup/errgroup.go:57 +0x57
created by golang.org/x/sync/errgroup.(*Group).Go
	/go/pkg/mod/golang.org/x/sync@v0.0.0-20181221193216-37e7f081c4d4/errgroup/errgroup.go:54 +0x66

goroutine 8193428 [semacquire, 886 minutes]:
sync.runtime_Semacquire(0xc00093ea98)
	/usr/local/go/src/runtime/sema.go:56 +0x39
sync.(*WaitGroup).Wait(0xc00093ea90)
	/usr/local/go/src/sync/waitgroup.go:130 +0x65
github.com/improbable-eng/thanos/pkg/store.(*ProxyStore).Series.func1.1(0xc00093ea90, 0xc000f70310)
	/go/src/github.com/improbable-eng/thanos/pkg/store/proxy.go:166 +0x2b
github.com/improbable-eng/thanos/pkg/store.(*ProxyStore).Series.func1(0x0, 0x0)
	/go/src/github.com/improbable-eng/thanos/pkg/store/proxy.go:220 +0x74a
golang.org/x/sync/errgroup.(*Group).Go.func1(0xc000e8d500, 0xc0008431d0)
	/go/pkg/mod/golang.org/x/sync@v0.0.0-20181221193216-37e7f081c4d4/errgroup/errgroup.go:57 +0x57
created by golang.org/x/sync/errgroup.(*Group).Go
	/go/pkg/mod/golang.org/x/sync@v0.0.0-20181221193216-37e7f081c4d4/errgroup/errgroup.go:54 +0x66

I may be out of my depth, but is the issue possibly that the buffered channel is full which is blocking on the function and prevents the wg.Done() call from being reached?
I'll test it out on my local installation and report back if any difference is made.
(Referring to this part of the startStreamSeriesSet function, which is called by this part of the Serires function in pkg/store/proxy.go)

Following up on my previous comment, this is definitely resolved by #1082. No stale goroutines or Prom queries have been observed in the 10 days since I started running a newer release of Thanos.
This issue should be able to be closed.

Thanks everyone involved! Was quite painful to dig it (:


Return to the URL after login

It would be nice if FOSSBilling automatically redirected back to the requested page after logging in.

Agreed, this seems like a logical and 'normal' behaviour.

Yes. It is expected behaviour!


Update docfx.json

add

Docs Build status updates of commit 9ae4e9b:
:clock10: Pending: waiting for processors (8 builds ahead of you)
:warning: Docs Build is busy, currently there are 8 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit 9ae4e9b:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details
Dependent Files

:x:Error

Details

Line 216: [Error] Call W:\uioi-s.optemp\packages\opbuild.postprocessorwrapper.1.73.0-alpha-20190419070247-ga5ce52a\tools\Microsoft.OpenPublishing.Build.Applications.PostProcessorWrapper.exe failed. Please retry building your content. If the issue still happens, open a ticket in http://SiteHelp.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Flaky kernel listing test

162 passing (13m)
121 pending
1 failing

DataScience - VSCode Notebook - (Remote Execution)
Local and Remote kernels are not listed:
AssertionError: Should have at least one remote kernelspec: expected false to be truthy
at Context. (src/test/datascience/notebook/remoteNotebookEditor.vscode.test.ts:170:16)

https://github.com/microsoft/vscode-jupyter/runs/8236545562?check_suite_focus=true

Looks like this applies to the kernel UI changes (i.e. type of the kernel picker thats displayed), hence assigning to @IanMatthewHuff
await changeShowOnlyOneTypeOfKernel(true);

fixed in latest main

Marking as verified, please unverify if you've seen this again...


Added base interceptor

Please add UnitTests for the changes

Ok, unit test in progress :+1:

Looks good to me..,  thank you
@ziur please take a look

:+1:


poets scripts for pash

Reverted the scripts to match the originals. The problem with awk and grep -c remains. scripts/trigrams_rec.sh invokes a second script, can the script be hardcoded into trigrams_rec?

Thanks!

scripts/trigrams_rec.sh invokes a second script, can the script be hardcoded into trigrams_rec?

For now we could leave it as is, and we can see what to do with it when we run a proper evaluation of PaSh on these scripts.

@angelhof We're inlining this script for now, and correcting double quotes to single quotes for awk.


TLS Improvements and Fixes

2 Commits.
https://github.com/graylog-labs/gelf-rb/commit/c60c049c5671a31dd2edcde9a377becfcaf3e97a
Adds the ability to allow the SSL Exceptions to rise up into the calling application.
This is very useful when debugging TLS errors, as the current implementation just eats them, leaving the user none-the-wiser as to why things aren't working.
https://github.com/graylog-labs/gelf-rb/commit/28d35996d71a03eaf574233533ec9baf549cb760
Uses the correct syntax for the CipherString. The Jruby wrapper of SSL cannot take CipherNames directly and must use TXT constants from this list - https://github.com/jruby/jruby-openssl/blob/master/src/main/java/org/jruby/ext/openssl/CipherStrings.java#L47-L178

Hi, Is there anything more I should to do this PR to make it more likely to get merged?

I'll try adding TLSv1.2, too. jruby/jruby#1737 suggests that it will work.

Rebased this to resolve merge conflicts and pushed to master. Also added TLS 1.1 and 1.2 as well. Thank you for the contribution! :+1: If you have a JRuby application at hand, it would be fantastic if you could test current master with this change! I'm planning to release a new version next weekend, will be testing the current version with a TCP TLS connection on regular Ruby.


Running Find inside Transaction will panic due to s.db being nil

Reproduce
// store_test.go

func (s *StoreSuite) TestTransaction_Query() {
	err := s.store.Transaction(func(store *Store) error {
		q := NewBaseQuery(ModelSchema)
		q.Select(NewSchemaField("name"), ModelSchema.ID())
		_, err := store.Find(q)
		s.Nil(err)
		return nil
	})
	s.Nil(err)
}

The problem (I think) is that newStoreWithTransaction returns a *Store with proxy and builder set, db empty. Then in places like Find, RawQuery and RawUpdate, uses s.db directly.
I don't know squirrel enough, but can we simply swap out s.db with s.proxy instead?

Thanks for reporting! will be fixing this ASAP.