Datadog Agent Forwarder fails liveness probe when new spot instance joins cluster, causing multiple restarts

Output of the info page (if this is a bug)

==============
Agent (v6.0.0)
==============

  Status date: 2018-05-15 17:28:44.007680 UTC
  Pid: 326
  Python Version: 2.7.14
  Logs:
  Check Runners: 1
  Log Level: WARN

  Paths
  =====
    Config File: /etc/datadog-agent/datadog.yaml
    conf.d: /etc/datadog-agent/conf.d
    checks.d: /etc/datadog-agent/checks.d

  Clocks
  ======
    System UTC time: 2018-05-15 17:28:44.007680 UTC

  Host Info
  =========
    bootTime: 2018-05-15 17:21:48.000000 UTC
    kernelVersion: 4.4.115-k8s
    os: linux
    platform: debian
    platformFamily: debian
    platformVersion: 9.3
    procs: 72
    uptime: 414
    virtualizationRole: guest
    virtualizationSystem: xen

  Hostnames
  =========
    ec2-hostname: ip-172-31-99-8.us-west-2.compute.internal
    hostname: i-0820f63f3cb2ffdc0
    instance-id: i-0820f63f3cb2ffdc0
    socket-fqdn: cluster-datadog-w2pc6
    socket-hostname: cluster-datadog-w2pc6

=========
Collector
=========

  Running Checks
  ==============
    No checks have run yet

========
JMXFetch
========

  Initialized checks
  ==================
    no checks

  Failed checks
  =============
    no checks

=========
Forwarder
=========

  IntakeV1: 1
  RetryQueueSize: 0
  Success: 1

  API Keys status
  ===============
    https://6-0-0-app.agent.datadoghq.com,*************************4d886: API Key valid

==========
Logs-agent
==========

  logs-agent is not running

=========
DogStatsD
=========

  Event: 1

kubectl describe pod output
  Normal   Pulled                 3m               kubelet, ip-172-31-99-8.us-west-2.compute.internal  Successfully pulled image "datadog/agent:6.0.0"
  Warning  Unhealthy              2m               kubelet, ip-172-31-99-8.us-west-2.compute.internal  Liveness probe failed: Agent health: FAIL
=== 1 healthy components ===
healthcheck
=== 13 unhealthy components ===
ad-autoconfig, ad-configresolver, ad-kubeletlistener, aggregator, collector-queue, dockerutil-event-dispatch, dogstatsd-main, forwarder, metadata-agent_checks, metadata-host, metadata-resources, tagger, tagger-docker
Error: found 13 unhealthy components
  Normal   Created    2m (x3 over 3m)  kubelet, ip-172-31-99-8.us-west-2.compute.internal  Created container
  Warning  Unhealthy  2m (x4 over 2m)  kubelet, ip-172-31-99-8.us-west-2.compute.internal  Liveness probe failed: Agent health: FAIL
=== 13 healthy components ===
ad-autoconfig, ad-configresolver, ad-kubeletlistener, aggregator, collector-queue, dockerutil-event-dispatch, dogstatsd-main, healthcheck, metadata-agent_checks, metadata-host, metadata-resources, tagger, tagger-docker
=== 1 unhealthy components ===
forwarder
Error: found 1 unhealthy components
  Normal  Killing  2m (x2 over 2m)  kubelet, ip-172-31-99-8.us-west-2.compute.internal  Killing container with id docker://datadog:Container failed liveness probe.. Container will be killed and recreated.
  Normal  Pulled   2m (x2 over 2m)  kubelet, ip-172-31-99-8.us-west-2.compute.internal  Container image "datadog/agent:6.0.0" already present on machine
  Normal  Started  2m (x3 over 3m)  kubelet, ip-172-31-99-8.us-west-2.compute.internal  Started container

Describe what happened:
We are running our cluster in AWS using with master nodes as on-demand instances, and worker nodes as spot instances. When we lose a spot node, and a new one rejoins, datadog frequently restarts on the node, about 6 times, until it runs normally again. The reason datadog is restarting is that the liveness probe fails, due to the forwarder being unhealthy.
Describe what you expected:
The forwarder to be healthy when deployed on the fresh node.
Steps to reproduce the issue:
On a kubernetes cluster running 1.8.7, with worker nodes on spot, and an autoscale group for the worker nodes, delete a worker node, and wait for a new node to join the cluster. Once the new node has joined the cluster, monitor the datadog pod scheduled on the node.
Additional environment details (Operating System, Cloud provider, etc):
Cloud Provider: AWS
Kubernetes Version: 1.8.7
Datadog Version: 6.0.0

Here's the output of kubectl get pods:

Actually it looks like it even does this when a new master node comes up

An init container with sleep 300 seems to help mitigate it

Hi @ihoegen ,
Thanks for reaching out!
We are currently working on this issue. There are different network setups where the forwarder is slow to startup, and then is unhealthy at the end of the expected startup time.
We'll update you with our advances on this end, thank you for your patience!
Best regards

Awesome, thank you. I'll update the team

Hey @ihoegen
A quick question: could you please confirm if you are using a proxy on this agents? If it is the case, we should be shipping a fix for this right now.
Thanks

@antoinepouille how would I be able to check?

@ihoegen If you didn't set it in the config of the agent, you're most likely not using a proxy…
Would you mind opening a support case so that one of our support engineers can help you with more details?

I'm seeing the same behavior using stable/datadog chart:
`Events:
Type     Reason                 Age               From                                                 Message

Normal   SuccessfulMountVolume  6m                kubelet, ip-172-20-62-47.us-east-2.compute.internal  MountVolume.SetUp succeeded for volume "dockersocket"
Normal   SuccessfulMountVolume  6m                kubelet, ip-172-20-62-47.us-east-2.compute.internal  MountVolume.SetUp succeeded for volume "procdir"
Normal   SuccessfulMountVolume  6m                kubelet, ip-172-20-62-47.us-east-2.compute.internal  MountVolume.SetUp succeeded for volume "cgroups"
Normal   SuccessfulMountVolume  6m                kubelet, ip-172-20-62-47.us-east-2.compute.internal  MountVolume.SetUp succeeded for volume "datadog-datadog-token-fscvg"
Normal   Started                5m (x3 over 6m)   kubelet, ip-172-20-62-47.us-east-2.compute.internal  Started container
Normal   Pulled                 5m (x4 over 6m)   kubelet, ip-172-20-62-47.us-east-2.compute.internal  Container image "datadog/agent:6.2.1" already present on machine
Normal   Created                5m (x4 over 6m)   kubelet, ip-172-20-62-47.us-east-2.compute.internal  Created container
Normal   Killing                5m (x3 over 6m)   kubelet, ip-172-20-62-47.us-east-2.compute.internal  Killing container with id docker://datadog:Container failed liveness probe.. Container will be killed and recreated.
Warning  Unhealthy              1m (x14 over 6m)  kubelet, ip-172-20-62-47.us-east-2.compute.internal  Liveness probe failed: Agent health: FAIL
=== 12 healthy components ===
ad-autoconfig, ad-configresolver, ad-kubeletlistener, aggregator, collector-queue, dogstatsd-main, healthcheck, metadata-agent_checks, metadata-host, metadata-resources, tagger, tagger-docker
=== 1 unhealthy components ===
forwarder
Error: found 1 unhealthy components`
Any updates on this?

Any outcome on this issue

@willyyang @gtrembathcafex I simply update the timeouts of the liveness probe in the daemon set deployment yaml and I'm not experiencing any issues anymore. I have some very high log-volume applications so I thought that might influence it. In my case I I increased initialDelaySeconds from 15 to 30 and timeoutSeconds from 1 to 5.

Hi all,
This issue is old and applies to agent 6.0.0. Recent occurrences of it are likely unrelated to the original report. We changed the status reporting system to solve the forwarder flakiness a while ago, and moved from an exec based mechanism to an http-based one 5 months ago.
If you have seen flaky health checks less than 5 months ago, please open a separate issue.
If you experience healthchecks that are slow to succeed at init, this is likely due to resource limits being too low. The default 256 Mi memory / 200m cpu are good defaults with only the metrics agent enabled, but if you enable traces and/or logs collection these limits likely slow the agent down, making it start late.
If increasing limits doesn't help, please open a separate issue or support ticket as well.

moved from an exec based mechanism to an http-based one 5 months ago

Does this mean the daemonset should not be using probe.sh for the liveness check? If so what should the probe be?

probe.sh should still work, but we have experienced some issues with containerd and exec-based probes (not specific to the agent container), so we have moved to an http-based liveness probe as a precaution: https://github.com/DataDog/datadog-agent/blob/1c117b0c6f256ffdf6512c18ccd8eac6e809b295/Dockerfiles/manifests/agent.yaml#L44-L52


doc: cover the inline-specified variants of arguments to oci_image

Fixes bazel-contrib/rules_oci#698

could you fix the docs?  run bazel test //docs/... and see to logs for how to fix it.

Looks like there was a flake, do you mind rebasing?


chunked upload support

My first thought was "how will this interact with MAX_CONTENT_LENGTH," and I see it just acts as if a chunked upload will be larger.  I think that's the simplest correct solution.
I like this implementation a lot.
Out of curiosity, when do clients send via chunked encoding in the wild?  I've not encountered this yet.

It was a strongly desired request from a Pushpin user needing to do large uploads. I believe it is needed if you are doing streaming gzip of the request body, since the Content-Length would be unknown in that case.

And yeah a larger buffer is needed to ensure we have enough room to process chunks (apparently there is no chunk size limit or standard so we just have to pick something large). I considered increasing MAX_CONTENT_LENGTH, but since chunked uploads will be very rare it didn't seem justifiable to make a major buffering change for the common case.

Hello, I have devices that send request using chunked transfers. They are under 2K size. Is there a way to configure it to process those as usual? I can not use upload storage I receive hundreds of small requests per seconds and I need to have workers on multiple servers.

Checking the code, it seems it is not possible to receive a "small" request body the normal way, if Content-Length is not specified.
The problem is that the body cannot be determined to be small until it is read. Probably this could be fixed in connection.c, in the block containing the Upload_file call, by attempting to read up to MAX_CONTENT_LENGTH chunked bytes beforehand, then being smart about what to do next. It's important that such buffering is not performed when upload.stream is enabled though.
I can't work on this, but I think it would be a reasonable PR.
The other idea is to use upload.stream with an adapter process that lives with mongrel2. IMO this is probably best anyway, because you could enforce body sizes without worry of large ones spilling over into files.


WIP: VCS Integration

Baby steps to integrate dobi with git

Based on discussion in https://github.com/dnephin/dobi/issues/40#issuecomment-255237807 I think we should support this with "recipes" by allowing urls in meta.include and caching the files, so I'm going to close this PR.


Inconsistent treatment of Windows-style paths

As discussed in #471 ...
When building a jupyter-book on Windows, is the user supposed to use Windows-style paths in toc.yml? The docs are silent on this issue.
I don't have a Windows machine to test this on myself, but I'm having trouble following the logic in the code base. E.g. this line:
https://github.com/jupyter/jupyter-book/blob/dc45f5a7571e8797b65c22a0def06dd5d1a75c6a/jupyter_book/build.py#L174
would seem to expect that url_page contains an os-specific relative path -- but also tries to strip off the character /.

Closing as this should be superceded by beta.jupyterbook.org


Update About Section

Could you add more details about this?

@davidsth I guess this is resolved. current changes are fine.


I don't really want to reopen this, but it's still not clear what you used for training and testing. In plinder-pl50.parquet you have this many systems for train/val/test:

          I don't really want to reopen this, but it's still not clear what you used for training and testing. In plinder-pl50.parquet you have this many systems for train/val/test:

'train': 255463, 'removed': 151133, 'test': 15132, 'val': 13896
In the preprint you report: 57,602 / 3,453 / 308
This does not correspond to the numbers in the parquet file-
If I take all the unique clusters (not sure what is different between the clusterings?)I get:
x[x.split=='test'].cluster.unique().shape
(5842,)

x[x.split=='test'].cluster_for_val_split.unique().shape
(1902,)

What has really been used here?
Is it possible to get a file which lists what ids are in the 57,602 / 3,453 / 308 from the preprint in a simple csv?
Best,
Patrick
Originally posted by @patrickbryant1 in https://github.com/plinder-org/plinder/issues/20#issuecomment-2322023047

The split for retraining DiffDock is here: gs://plinder/2024-04/v0/splits/plinder-pl50.parquet (57734/3459/3758), with discrepancy due to Diffdock failures in processing (so the split that diffdock fully processed and with posebusters systems removed from test which matches the numbers in the table is in gs://plinder/2024-04/v0/splits/plinder-no-posebusters.parquet). This was in the Changelog in the README but we're moving docs around and it got removed, now added back.
Note that this split was only on a single ligand subset with (too) strict nonredundancy filters, and was used to demonstrate that an automated split can achieve as low leakage as a curated one. We've made a number of updates to improve annotations and splitting, and would recommend the v2 split.

Hi,
Thanks for the quick reply.
Great, then we get it
Best,
Patrick


smithy-model: add support for httpContentMd5 trait

Issue #, if available:
Description of changes:

add support for httpContentMd5 trait

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Thanks for the PR! Could you move this trait to the smithy-aws-traits package? I think that this trait isn't generic enough since I've never heard of any other service requiring a Content-MD5 on input like the way S3 does. The trait would go here: https://github.com/awslabs/smithy/blob/0.10/smithy-aws-traits/src/main/resources/META-INF/smithy/aws.protocols.json, in the aws.protocols namespace.

I agree the trait isn't too generic, and can be moved to smithy-aws-traits package. But the trait isn't protocol specific, so curious why aws.protocols namespace? why not aws.api namespace instead as it seems to have traits like ClientDiscoveredEndpoint which target operations/services?

Good question... I thought about aws.api too, but I kind of think this is protocol-specific in that it only applies to HTTP based application protocols.

That seems more transport specific, but i guess it's better keeping it in aws.protocol rather than aws.api.
I have pushed a change for the trait to be in aws.protocols namespace.
A follow-up question wrt the pushed change is if we need to move the HttpContentMd5Trait class from software.amazon.smithy.aws.traits to software.amazon.smithy.aws.traits.protocols sub package?
Let me know once you get time to review this.

Thanks. Yeah all the code needs to move to that package too.

Moved HttpContentMd5Trait class  to software.amazon.smithy.aws.traits.protocols pkg
Let me know if PR needs changes. Thanks!


Add support for HTC One (M9)

Current status: Boots the PE ramdisk from internal storage, sd card isn't supported yet (it seems to be different from the "standard" setup, yet to be investigated).


where to find details about your project?

hi i would like to know if you have a website, discord, twitter or any other socials that I can join to find more information about this project would be really nice, I have not been able to find anything so far!

Hi. You can find for foin crypto is financial.org invest first, register and use this reference number 27026348.
And than you can find foin.
For guide you can open :

foin.io
http://explorer.foin.io
Wallet.crypto-bridge.org
This is my whatsapp : +6282316173000

Thank you.

All relevant information can be found on our website, www.foin.io.
If you need any help with non-technical aspects of our projects, please use the contact email address listed on our website.
Thanks for your interest


add support for skip Sentry init

Fixes #
Description of the changes

Would be great for us if this is merged (so it doesn't overwrite our existing Sentry.init setup), is there anything we can do to support? Thanks a lot for maintaining this package!

Would be great for us if this is merged (so it doesn't overwrite our existing Sentry.init setup), is there anything we can do to support? Thanks a lot for maintaining this package!

Hi @bensalilijames
I am closing this PR, i published new version, 1.0.5 with this feature.
Thanks

Amazing, thanks so much!


Space typos in ERS codes prevents programatic usage

Describe the bug
Some entries in archive_accession fields have accidently left in spaces which breaks programmatic processing. We should ensure this field does not contain them with a regex in the JSON (or in AncientMetagenomeDirCheck).
Examples are:
SRS3078134, SRS3078129 (in the middle)
SRS3078134,SRS3078129  (at the end)
Additional context
Add any other context about the problem here such as supporting citations or referennces

For reference, this is the solution:
"archive_accession": {
                "$id": "#/items/properties/archive_accession",
                "type": [
                    "string",
                    "null"
                ],
                "pattern": "[^ ]*",
                "title": "Archive accession number",
                "description": "Samples archive accession numbers, multiple records can be separated with commas. No spaces allowed",
                "examples": [
                    "SRS473742,SRS473743,SRS473744,SRS473745"
                ]
            }

Waiting for other issues to be fixed to propose it as a PR

For reference, this is the solution:
"archive_accession": {
                "$id": "#/items/properties/archive_accession",
                "type": [
                    "string",
                    "null"
                ],
                "pattern": "[^ ]*",
                "title": "Archive accession number",
                "description": "Samples archive accession numbers, multiple records can be separated with commas. No spaces allowed",
                "examples": [
                    "SRS473742,SRS473743,SRS473744,SRS473745"
                ]
            }

Waiting for other issues to be fixed to propose it as a PR


Screen recording fails to this application Calculator , Alarm & Clock, Microsoftoutlook

i used ffmpeg with Windows 10 OS
FFmpeg do recording well and excellent for Desktop as well as title=
title=windowname  lke title=notpad, title = any application window name it work fine
but the problem it that when we try to record title=Calculator or title=Alarm&Clock or Title=Inbox -outlook
FFmpeg shows window found but for this three application , it only record Black window with mouse course and its movement ,
i unable to trace exact issue and how to solve this i try almost all with gdigrab options can you please help me to record screen for this application. is something i missed for this application

Please direct usage-questions to the ffmpeg-user mailinglist or #ffmpeg on Libera.Chat.


when launch spyder , a window show there's error occurs

Description
What steps will reproduce the problem?

What is the expected output? What do you see instead?
Please provide any additional information below
Version and main components

Spyder Version: 3.2.4
Python Version: 3.6.3
Qt Versions: 5.6.2, PyQt5 5.6 on Windows

Dependencies
pyflakes >=0.6.0 :  1.6.0 (OK)
pycodestyle >=2.3:  2.3.1 (OK)
pygments >=2.0   :  2.2.0 (OK)
pandas >=0.13.1  :  0.20.3 (OK)
numpy >=1.7      :  1.13.3 (OK)
sphinx >=0.6.6   :  1.6.3 (OK)
rope >=0.9.4     :  0.10.5 (OK)
jedi >=0.9.0     :  0.10.2 (OK)
nbconvert >=4.0  :  5.3.1 (OK)
sympy >=0.7.3    :  1.1.1 (OK)
cython >=0.21    :  0.26.1 (OK)
qtconsole >=4.2.0:  4.3.1 (OK)
IPython >=4.0    :  6.1.0 (OK)
pylint >=0.25    :  1.7.4 (OK)

Thanks for reporting. Unfortunately, your error report doesn't contain any information, such as a traceback or error message, a detailed description of whether if it worked before, what you did preceding the error, and what you tried to fix it, and information on anything particular to your setup and how you installed Spyder, that would allow us to address it. In any case, this is most likely a user-side issue that can be resolved by a clean install of the up to date Anaconda distribution, or by running spyder --reset from the Anaconda prompt. Therefore, this issue will be closed promptly.
If you are able to provide at least some of this information to allow us to see if it is an issue with Spyder and if so, fix it from our end, then you are welcome to do so and reopen this issue. Best of luck!


The BannerPlugin has no documentation in webpck 2

There is no documentation of the BannerPlugin on https://webpack.js.org/plugins. How would I add a new plugin page as a PR?

Go to https://github.com/webpack/webpack.js.org/new/master/content/plugins and input banner-plugin.md as filename. Make sure to include a minimal yaml header at the top of the file:
---
title: banner-plugin
---

BannerPlugin docs have been added in #779.

Followed the above link and instructions. Have only found the commit for the banner-plugin.md file which actually points to older documentation of the banner-plugin? Searched it myself which resulted in the following link:  https://github.com/webpack/webpack.js.org/blob/master/src/content/plugins/banner-plugin.md
Posting this so it could help others in the future when searching for the banner-plugin docs.


bot/basehandlers: add support for CTCP BOTINFO

Ping @nyuszika7h to make sure this looks okay.

"looks okay I guess" -- @nyuszika7h


Update non-gate quantum ops to have gates

Describe your design idea/issue
It would be nice to make things consistent such that quantum operations (as opposed to control operation classes like subcircuits and feedforward) all have associated gates. Most do. The ones I see that don't are:

BooleanHamiltonean: This seems straightforward to convert: instead of qubit_map, the BooleanHamiltoneanGate.init would just take a list of names, and then implement the decompose_once_with_qubits protocol to create the qubit_map on demand using self.names and the passed in qubits.
PauliStringPhasor and PauliStringGateOperation: Haven't looked at these.
GlobalPhaseOperation: This is always an oddball. But we could make a GlobalPhaseGate easily enough and it would fit better in some ways. Granted, GlobalPhaseGate().on(tuple()) is weird. But it does play well with other gates, like if someone wanted a function that zipped up gates and qubits, this would allow them to add global phases to that.

The advantages of doing this are:

Gates are more reusable (you can have my_x=X**0.8 and then apply that to different qubits, etc. With an op you'd have to **0.8 each time). With things like BooleanHamiltonean this could be nice too.
They fit cleaner in gatesets (GlobalPhaseGate would likely allow for cleanup of some existing gateset code)
You can typically operate on them at a lower level, e.g. with state vectors and axes, rather than requiring qubits and full simulators.
Consistency for consistency's sake.

Disadvantages:

e.g. GateOperation(PauliStringPhasorGate(), q) is not the same as PauliStringPhasorGate.on(q): we still want the latter to return a PauliStringPhasorOperation because it has extra functionality. So maybe this is confusing.

There's also ArithmeticOperation; QuirkInputRotationOperation.

Regarding the disadvante mentioned:
There are many operations which are not gate operations but have a .gate property. The confusing case that you mentioned would be applicable to all those cases. Eg: controlled_gate.on(*q) is not same as GateOperation(controlled_gate, q). Another prominent example is PauliString (operation) vs DensePauliGate (corresponding gate)

Gates are more reusable (you can have my_x=X**0.8 and then apply that to different qubits, etc. With an op you'd have to **0.8 each time). With things like BooleanHamiltonean this could be nice too.

With ops you can do ops.with_qubits() to apply them to different qubits.

Related: #1561

@tanujkhattar: It looks like ArithmeticOperation will be possible to make into a gate. I don't think QuirkInputRotationOperation will be possible though, since it wraps another Operation. To make a gate, we'd have to redesign the thing so that it wraps a Gate instead, which, IDK if that fits with what QuirkInputRotationOperation is supposed to do. If so, then probably it's possible to change that to a gate too, but IDK if the ROI is there.

@tanujkhattar Looking again, I believe the QuirkInputRotationOperation would be a valid candidate. It can wrap a gate instead of an operation. Of course, that means it's limited to wrapping gates, but the point of this project is to push as many things down to the gate level as it makes sense to do. So, it won't be able to wrap a CircuitOperation or a ClassicallyControlledOperation. Which makes sense, and is probably better.

This would be useful towards the 1.0 roadmap item for organizing gate relationships.
xref #3242

@tanujkhattar can you add the pre-1.0 tag to this one? https://github.com/quantumlib/Cirq/pull/4705 and https://github.com/quantumlib/Cirq/pull/4702 are still pending review.

I've added it.


Change the default audit.log path

How to categorize this PR?

/area control-plane
/kind bug
What this PR does / why we need it:
Since the default user that is used to run the gardener-apiserver was changed to a nonroot user which does not have permissions to write in /var/lib/audit.log we change the default location of the logs.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Release note:

The default value for `--audit-log-path` of Gardener API Server was changed from `/var/lib/audit.log` to `/tmp/audit/audit.log` so that a `nonroot` user can access it without additional permissions.

/lgtm
/approve
Can you please add a release note?

/test pull-gardener-e2e-kind

/test pull-gardener-e2e-kind

/test pull-gardener-e2e-kind

/test pull-gardener-e2e-kind


How to handle branch merges with this plugin?

When you merge one branch into another, git will create messages like Merged branch 'master' into xyz, which obviously does not match the conventional commit pattern.
What is the general approach using this plugin? Is it possible to exclude those?

Hi @mklueh,
The best approach I could suggest is to use rebase instead of merge as a merge method for a branch.
Using the rebase you don't have a merge commit and the history is linear. In this case, the plugin works fine.
Currently, there aren't any methods to "suppress" the check. But I will investigate a way to suppress the check, somehow :)
If you want to use the merge as a merge strategy, you could modify the commit message to make it conventional commit compliant. For example, if the merge commit is the last one in the local history, you could modify it with `git commit --amend" and edit the commit message (chore: Merge branch 'master' into XYZ).

@nicolasfara Thank you!
Not sure if rebasing is an option in our case. Adjusting the commit message could be an idea :)
Would it be possible to exclude merges from the hook in general? For example, current scenario:
One college merged a non-conventional commit into master, because the plugin is currently not on master.
I try to merge master into my branch, and the plugin complains that merging is not possible because of non-conventional commits.
Now in order to get it merged, I had to go to .git/hooks and delete the hook of the plugin.
Would it make sense to ignore those merges and just focus on "normal" local commits?

I am also running into something like this trying to use the plugin. My CI/CD is failing in my GitLab MR because it cannot get the hook messages.

I tried to fix this issue by releasing a new plugin version that makes it possible to configure a regex so that if a commit message matches it, the check succeeds.
Please don't hesitate to reopen this issue if there are problems with this approach.
The settings key added is ignoreCommitMessage and a regex should be specified.

:tada: This issue has been resolved in version 3.1.0 :tada:
The release is available on:

3.1.0
3.1.0
GitHub release

Your semantic-release bot :package::rocket:


Add-ons downloads count is always zero

Describe the problem and steps to reproduce it:
In the statistics panel the download are always zero for all my add-ons.
Example: https://addons.thunderbird.net/it/thunderbird/addon/thunderai/
From the statistics dashboard:

Download dashboard:

What happened?
The downloads are always zero.
What did you expect to happen?
To count some download, given that the daily users are always growing.

After a bit of investigating, it seems we don't actually support the infrastructure to calculate downloads right now. This may change in the future, so I'm tagging this as an enhancement.

See https://github.com/thunderbird/addons-server/issues/80


Build failed with exception

I am using ubutntu 22.04 my java version is 8
The error that i have been getting is
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':grobid-service:run'.

Process 'command '/usr/lib/jvm/java-8-openjdk-amd64/bin/java'' finished with non-zero exit value 1

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

Get more help at https://help.gradle.org

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.
You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.
See https://docs.gradle.org/7.1.1/userguide/command_line_interface.html#sec:command_line_warnings
BUILD FAILED in 18s
9 actionable tasks: 3 executed, 3 from cache, 3 up-to-date
Stacktrace  command
https://drive.google.com/drive/u/0/search?q=sta
WIth  info command
https://drive.google.com/drive/u/0/search?q=info

Hi @sarique2003 !
I can't access the traces on google drive.
Could you also indicate the version of grobid you are using?

Stacktrace = [https://drive.google.com/drive/u/0/search?q=sta]
info = [https://drive.google.com/drive/u/0/search?q=info]
Sorry for the mishap providing working links

@sarique2003 I am sorry, still can't access - these are search requests on google drives, not artifacts.
If the stack traces are not too long, you could just cut and paste here, with the command line you used.
Maybe you'd want to try more recent versions like 0.7.2 too ? (all should work fine on your environment)

Will try with newer version
On Sun, 4 Dec 2022, 16:33 Patrice Lopez, @.***> wrote:

@sarique2003 https://github.com/sarique2003 I am sorry, still can't
access - these are search requests on google drives, not artifacts.
If the stack traces are not too long, you could just cut and paste here,
with the command line you used.
Maybe you'd want to try more recent versions like 0.7.2 too ? (all should
work fine on your environment)
—
Reply to this email directly, view it on GitHub
https://github.com/kermitt2/grobid/issues/976#issuecomment-1336380644,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AWGFDVZ6OWW2USAMG7YCTLDWLR3ABANCNFSM6AAAAAASS26FQQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

https://drive.google.com/file/d/1wqtVpKBgVe4JXo9ILDJWI1szZWmZJmP5/view?usp=share_link =Stacktrace
https://drive.google.com/file/d/1zoXHHWteyOyziGRbMVShG9Hyuv7WGglt/view?usp=share_link= info

Thank you @sarique2003  !
Looking at the traces, the build is fine, the problem is running the service. It is due to a linking issue from the native Wapiti libraries which are included in Grobid.
Caused by: java.lang.UnsatisfiedLinkError: /home/ravenclaw/Desktop/grobid/grobid-home/lib/lin-64/libwapiti.so: /home/ravenclaw/Desktop/grobid/grobid-home/lib/lin-64/libpthread.so.0: undefined symbol: __vdso_clock_gettime, version GLIBC_PRIVATE

It means that the native libraries shipped with Grobid try to link with your system libraries (which are incompatible, but it's normal) instead of the local libraries in the same directory (the other .so under grobid/grobid-home/lib/lin-64, in your case the local libc.so.6 normally).

Be sure to use a stable version and not the master. I've updated recently the native binaries and you are maybe using some unstable versions of the master native libraries, which could be a problem. You can download the releases here and build/run from a release, not from the git repo to be sure to work with the stable versions.

If you type:

ldd grobid/grobid-home/lib/lin-64/libwapiti.so

The listed dependent libraries should have a local path (to grobid/grobid-home/lib/lin-64/ or just a local address), it should not reference your system libraries.

If you build/run from the current master only, it should normally work since 579939bb857badded0995d4ff74fe3bad5f9f485 (a git pull might be necessary).

Thank you @kermitt2 , the server is running now guess the version i was using was unstable, thanks again


Unify way of handling gas calculation with traces

Which components does the task require to be changed?
snforge
Description
We should unify how we handle has calculation all across the board, so that the result we output are directly correlated (summed up) to the trace fragments with associated costs.

Blocked by #1541

blocked by #1752

@piotmag769 feel free to reopen if it's relevant, but it doesn't seem to be anymore


Behavior for directories with 0o000 permissions does not match native filesystems

Describe the bug
The behavior of file operations on directories with 0o000 permissions does not match the behavior of native filesystems for at least rmdir and chmod operations. The owner of a file/dir with 0o000 perms should always be able to remove or chmod them again, but pyfakefs does not respect this.
I've attached both a pytest test suite and bash script that demonstrates these operations and confirmed the behavior is the same on Ubuntu 18.04 and MacOS 12.5.1.
How To Reproduce
Here's a set of Pytest cases that show the operations passing natively and failing when run in pyfakefs. You can also directly run the python test file without using pytest to get an annotated output of the test.

            The error message is constructed from the given error code and shall
            start with the error string issued in the real system.
            Note: this is not true under Windows if winerror is given - in this
            case a localized message specific to winerror will be shown in the
            real file system.

            Args:
                err_no: A numeric error code from the C variable errno.
                filename: The name of the affected file, if any.
                winerror: Windows only - the specific Windows error code.
            """
        message = os.strerror(err_no) + ' in the fake filesystem'
        if (winerror is not None and sys.platform == 'win32' and
                self.is_windows_fs):
            raise OSError(err_no, message, filename, winerror)
>       raise OSError(err_no, message, filename)
E       PermissionError: [Errno 13] Permission denied in the fake filesystem: '/tmp/test-chmod'

/home/jesse.cureton/.local/lib/python3.6/site-packages/pyfakefs/fake_filesystem.py:1122: PermissionError
------------------------------------------------------------------------------------- Captured stdout call -------------------------------------------------------------------------------------
Creating test directory set setting permissions to 000
/tmp/test-chmod has permissions 0o0

Listing test dir - expect to get permissions denied
Got PermissionError: [Errno 13] Permission denied in the fake filesystem: '/tmp/test-chmod'

Chmod test dir to 600 - expect to pass and print new permissions
============================================================================== 1 failed, 1 passed in 0.32 seconds ==============================================================================

As a bonus, here's a Bash script that runs the same test to confirm that this does behave as expected. I've confirmed this on both MacOS and Linux.

Bash test case
#!/bin/bash

set +euo pipefail

cd /tmp

echo "Creating test directory set setting permissions to 000"
mkdir test-chmod
chmod 000 test-chmod
ls -la . | grep test-chmod
echo

echo "Listing test dir - expect to get permissions denied"
ls -la test-chmod/
echo

echo "Chmod test dir to 600 - expect to pass and print new permissions"
chmod 600 test-chmod
ls -la . | grep test-chmod
echo

echo "Set permissions back to 000"
chmod 000 test-chmod
ls -la . | grep test-chmod
echo

echo "Remove test directory while permissions 000 - expect to pass and show no such directory"
rmdir test-chmod
ls -la test-chmod
echo

Your environment
On MacOS:
jesse.cureton@Jesses-MacBook-Pro:/tmp$ python3 -c "import platform; print(platform.platform())"
macOS-12.5.1-x86_64-i386-64bit
jesse.cureton@Jesses-MacBook-Pro:/tmp$ python3 -c "import sys; print('Python', sys.version)"
Python 3.9.9 (main, Nov 21 2021, 03:23:42)
[Clang 13.0.0 (clang-13<IP_ADDRESS>)]
jesse.cureton@Jesses-MacBook-Pro:/tmp$ python3 -c "from pyfakefs.fake_filesystem import __version__; print('pyfakefs', __version__)"
pyfakefs 4.7.0

On Ubuntu:
jesse.cureton@jesse:~/debugging_logs/20220923_pyfakefs_bug_report$ python3 -c "import platform; print(platform.platform())"
Linux-5.4.0-1083-aws-x86_64-with-Ubuntu-18.04-bionic
jesse.cureton@jesse:~/debugging_logs/20220923_pyfakefs_bug_report$ python3 -c "import sys; print('Python', sys.version)"
Python 3.6.9 (default, Jun 29 2022, 11:45:57)
[GCC 8.4.0]
jesse.cureton@jesse:~/debugging_logs/20220923_pyfakefs_bug_report$ python3 -c "from pyfakefs.fake_filesystem import __version__; print('pyfakefs', __version__)"
pyfakefs 4.6.3

Thanks for the report and the detailed description! I will have a look at the problem.

@jessecureton-aurora - should be fixed in master now, please check if it works for you.

@mrbean-bremen Thanks for getting this fixed!! Yes, I just confirmed that this passes my test cases locally - all seems well


Restore of UNC Paths within windows failing (reproducible)

Output of restic version
restic 0.9.6 compiled with go1.13.4 on windows/amd64
How did you run restic exactly?
Open elevated Powershell

> C:\restic_0.9.6_w\restic.exe version
restic 0.9.6 compiled with go1.13.4 on windows/amd64

> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      5.1.14393.3471
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.14393.3471
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>

> $env:RESTIC_PASSWORD = 'restic'

> C:\restic_0.9.6_w\restic.exe -r K:\ResticBackup\test init
created restic repository 562ab4bb33 at K:\ResticBackup\test
Please note that knowledge of your password is required to access
the repository. Losing your password means that your data is
irrecoverably lost.

> ls "\\<IP_ADDRESS>\Test Folder"

    Directory: \\<IP_ADDRESS>\Test Folder

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----       25.06.2020     00:49                Folder 1
d-----       25.06.2020     00:49                Folder 2

> ls "\\<IP_ADDRESS>\TestFolderNoSpace"

    Directory: \\<IP_ADDRESS>\TestFolderNoSpace

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----       25.06.2020     00:49                Folder 2
d-----       25.06.2020     00:49                Folder 1

> ls "K:\TestFolderNoSpace"
    Directory: K:\TestFolderNoSpace

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----       25.06.2020     00:49                Folder 2
d-----       25.06.2020     00:49                Folder 1

> ls "K:\Test Folder"

    Directory: K:\Test Folder

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----       25.06.2020     00:49                Folder 1
d-----       25.06.2020     00:49                Folder 2

> C:\restic_0.9.6_w\restic.exe -r K:\ResticBackup\test backup "\\<IP_ADDRESS>\Test Folder"
repository 562ab4bb opened successfully, password is correct
Fatal: unable to save snapshot: Lstat: CreateFile \?\UNC\<IP_ADDRESS>\Test Folder\<IP_ADDRESS>: The system cannot find the file specified.

> C:\restic_0.9.6_w\restic.exe -r K:\ResticBackup\test backup "\\<IP_ADDRESS>\Test Folder\"
repository 562ab4bb opened successfully, password is correct
error: CreateFile \?\UNC\<IP_ADDRESS>\Test Folder": The network name cannot be found.
Fatal: unable to save snapshot: Lstat: CreateFile \?\UNC\<IP_ADDRESS>\Test Folder\<IP_ADDRESS>: The system cannot find the file specified.

> C:\restic_0.9.6_w\restic.exe -r K:\ResticBackup\test backup "\\<IP_ADDRESS>\Test Folder\*"
repository 562ab4bb opened successfully, password is correct
error: CreateFile \?\UNC\<IP_ADDRESS>\Test Folder*: The filename, directory name, or volume label syntax is incorrect.
Files:           0 new,     0 changed,     0 unmodified
Dirs:            1 new,     0 changed,     0 unmodified
Added to the repo: 328 B
processed 0 files, 0 B in 0:00
snapshot 0427e9f3 saved

> C:\restic_0.9.6_w\restic.exe -r K:\ResticBackup\test backup "\\<IP_ADDRESS>\TestFolderNoSpace"
repository 562ab4bb opened successfully, password is correct
Fatal: unable to save snapshot: Lstat: CreateFile \?\UNC\<IP_ADDRESS>\Test Folder\<IP_ADDRESS>: The system cannot find the file specified.

> C:\restic_0.9.6_w\restic.exe -r K:\ResticBackup\test backup "\\<IP_ADDRESS>\TestFolderNoSpace\"
repository 562ab4bb opened successfully, password is correct
Files:           2 new,     0 changed,     0 unmodified
Dirs:            0 new,     0 changed,     0 unmodified
Added to the repo: 321 B
processed 2 files, 0 B in 0:00
snapshot 445b58ab saved

> C:\restic_0.9.6_w\restic.exe -r K:\ResticBackup\test backup "K:\TestFolderNoSpace"
repository 562ab4bb opened successfully, password is correct
Files:           0 new,     0 changed,     2 unmodified
Dirs:            0 new,     0 changed,     1 unmodified
Added to the repo: 0 B
processed 2 files, 0 B in 0:00
snapshot 01349c2b saved

> C:\restic_0.9.6_w\restic.exe -r K:\ResticBackup\test backup "K:\Test Folder"
repository 562ab4bb opened successfully, password is correct
Files:           2 new,     0 changed,     0 unmodified
Dirs:            1 new,     0 changed,     0 unmodified
Added to the repo: 563 B
processed 2 files, 0 B in 0:00
snapshot 56f82ecf saved

> C:\restic_0.9.6_w\restic.exe -r K:\ResticBackup\test snapshots
repository 562ab4bb opened successfully, password is correct
ID        Time                 Host        Tags        Paths
----------------------------------------------------------------------------------------
0427e9f3  2020-06-25 01:01:22  Core                    \\<IP_ADDRESS>\Test Folder\*
445b58ab  2020-06-25 01:01:39  Core                    \\<IP_ADDRESS>\TestFolderNoSpace\
01349c2b  2020-06-25 01:02:04  Core                    K:\TestFolderNoSpace
56f82ecf  2020-06-25 01:02:16  Core                    K:\Test Folder
----------------------------------------------------------------------------------------
4 snapshots

> C:\restic_0.9.6_w\restic.exe -r K:\ResticBackup\test restore 0427e9f3 --target "K:\restore"
repository 562ab4bb opened successfully, password is correct
restoring <Snapshot 0427e9f3 of [\<IP_ADDRESS>\Test Folder*] at 2020-06-25 01:01:22.7598049 +0200 CEST by CORE\core@Core> to K:\restore
ignoring error for : invalid child node name \<IP_ADDRESS>\Test Folder
ignoring error for : invalid child node name \<IP_ADDRESS>\Test Folder
There were 2 errors

> C:\restic_0.9.6_w\restic.exe -r K:\ResticBackup\test restore 445b58ab --target "K:\restore"
repository 562ab4bb opened successfully, password is correct
restoring <Snapshot 445b58ab of [\<IP_ADDRESS>\TestFolderNoSpace] at 2020-06-25 01:01:39.8898124 +0200 CEST by CORE\core@Core> to K:\restore
ignoring error for : invalid child node name \<IP_ADDRESS>\TestFolderNoSpace
ignoring error for : invalid child node name \<IP_ADDRESS>\TestFolderNoSpace
There were 2 errors

> C:\restic_0.9.6_w\restic.exe -r K:\ResticBackup\test restore 01349c2b --target "K:\restore"
repository 562ab4bb opened successfully, password is correct
restoring <Snapshot 01349c2b of [K:\TestFolderNoSpace] at 2020-06-25 01:02:04.243429 +0200 CEST by CORE\core@Core> to K:\restore

> C:\restic_0.9.6_w\restic.exe -r K:\ResticBackup\test restore 56f82ecf --target "K:\restore"
repository 562ab4bb opened successfully, password is correct
restoring <Snapshot 56f82ecf of [K:\Test Folder] at 2020-06-25 01:02:16.0841665 +0200 CEST by CORE\core@Core> to K:\restore

What backend/server/service did you use to store the repository?
Windows Path on Local Disk
Expected behavior
Restic cannot work with UNC Paths.
Actual behavior

There are minor problems at the backup Process when trying to backup a UNC Path with Spaces like:
> C:\restic_0.9.6_w\restic.exe -r K:\ResticBackup\test backup "\\<IP_ADDRESS>\Test Folder"
You'll have to use an additional backslash + wildcard like this:
> C:\restic_0.9.6_w\restic.exe -r K:\ResticBackup\test backup "\\<IP_ADDRESS>\Test Folder\*"
You don't need that with the Local Path equivalent: [...]"K:\Test Folder"

There is a major problem when you try to restore UNC Paths. It simply does not work and exit with:

ignoring error for \: invalid child node name \\<IP_ADDRESS>\TestFolderNoSpace
ignoring error for \: invalid child node name \\<IP_ADDRESS>\TestFolderNoSpace

Steps to reproduce the behavior
Do the exact same commands described above on a windows system with an elevated powershell.
Do you have any idea what may have caused this?
Restic cannot handle UNC Paths within powershell (also tested the restore with elevated cmd.exe)
Do you have an idea how to solve the issue?
No
Did restic help you today? Did it make you happy in any way?
You're doing an awesome job by developing this tool.
And yes it did a very good job so far.

I'm very sorry for not having responded earlier. This is a bug in the backup code and the restorer trips over it. If you backup an UNC path directly, restic creates file names with the UNC path in it (which should not happen). The restorer has a mechanism to detect file names which contain path separators (such as \ on Windows) and refuses to restore them.
This patch should allow restoring, but the real bug in the backup code should be fixed:
diff --git internal/restorer/restorer.go internal/restorer/restorer.go
index 29224149..84cc36c7 100644
--- internal/restorer/restorer.go
+++ internal/restorer/restorer.go
@@ -62,14 +62,14 @@ func (res *Restorer) traverseTree(ctx context.Context, target, location string,
 		// ensure that the node name does not contain anything that refers to a
 		// top-level directory.
 		nodeName := filepath.Base(filepath.Join(string(filepath.Separator), node.Name))
-		if nodeName != node.Name {
-			debug.Log("node %q has invalid name %q", node.Name, nodeName)
-			err := res.Error(location, errors.Errorf("invalid child node name %s", node.Name))
-			if err != nil {
-				return hasRestored, err
-			}
-			continue
-		}
+		// if nodeName != node.Name {
+		// 	debug.Log("node %q has invalid name %q", node.Name, nodeName)
+		// 	err := res.Error(location, errors.Errorf("invalid child node name %s", node.Name))
+		// 	if err != nil {
+		// 		return hasRestored, err
+		// 	}
+		// 	continue
+		// }

 		nodeTarget := filepath.Join(target, nodeName)
 		nodeLocation := filepath.Join(location, nodeName

I'm very sorry for not having responded earlier. This is a bug in the backup code and the restorer trips over it. If you backup an UNC path directly, restic creates file names with the UNC path in it (which should not happen). The restorer has a mechanism to detect file names which contain path separators (such as \ on Windows) and refuses to restore them.
This patch should allow restoring, but the real bug in the backup code should be fixed:
diff --git internal/restorer/restorer.go internal/restorer/restorer.go
index 29224149..84cc36c7 100644
--- internal/restorer/restorer.go
+++ internal/restorer/restorer.go
@@ -62,14 +62,14 @@ func (res *Restorer) traverseTree(ctx context.Context, target, location string,
 		// ensure that the node name does not contain anything that refers to a
 		// top-level directory.
 		nodeName := filepath.Base(filepath.Join(string(filepath.Separator), node.Name))
-		if nodeName != node.Name {
-			debug.Log("node %q has invalid name %q", node.Name, nodeName)
-			err := res.Error(location, errors.Errorf("invalid child node name %s", node.Name))
-			if err != nil {
-				return hasRestored, err
-			}
-			continue
-		}
+		// if nodeName != node.Name {
+		// 	debug.Log("node %q has invalid name %q", node.Name, nodeName)
+		// 	err := res.Error(location, errors.Errorf("invalid child node name %s", node.Name))
+		// 	if err != nil {
+		// 		return hasRestored, err
+		// 	}
+		// 	continue
+		// }

 		nodeTarget := filepath.Join(target, nodeName)
 		nodeLocation := filepath.Join(location, nodeName

@MichaelEischer wouldn't it be better to allow (and remove) \ at the beginning of the path during restor (at least as hotfix)?
It's seems still not be fixed and users (including me) do backups of shared folders 🤔
https://forum.restic.net/t/invalid-child-node-name-in-windows-restore/5874

With restic 0.16.0 the subfolder syntax should be able to work around the problem: restore “latest:\<IP_ADDRESS>\Test Folder”

i am not able to restore files to Windows,
is this issue still unresolved?
is this the final solution or a temporary solution?
With restic 0.16.0 the subfolder syntax should be able to work around the problem: restore “latest:\<IP_ADDRESS>\Test Folder”

is the following the final solution or a temporary solution?

It is only a workaround, hence a temporary solution. I've tried to solve the issue some time ago but that turned out to be more work than originally anticipated, so yes the issue still exists.
A proper fix will require modifying internal/archiver/tree.go to correctly handle volume names consisting of host and share name. restic automatically resolves collisions between backup target path names, which with UNC paths reaches a completely new level of complexity. For example what should happen when someone backs up restic backup host\share2 \\host\share1 \\host\share2 (note that the first host\share2 is not a UNC path). The result should likely be /host/share2, /host-1/share1 and /host-1/share2 (as paths within the snapshot). However, achieving that result will require a rewrite of the path collision handling.

backup/restic ls 797f219c871dbe3d84fd39f108c3f7f37221870b1b211eee0376825ddd5de6e6 latest:/server/Share --cache-dir cache --json --quiet

That command invocation cannot work. ls expects a snapshot id (optionally using the subfolder syntax) followed by a list of paths to filter for. That is restic ls latest, restic ls latest:/subfolder, restic ls 797f219c871dbe3d84fd39f108c3f7f37221870b1b211eee0376825ddd5de6e6 or restic ls latest /subfolder are valid syntax. In your case you'll likely want the following:
restic ls latest:\\server\Share/subfolder

(The UNC part uses backslashes, whereas subfolders within the volumes are separated by forward slashes)
I'm not entirely sure whether the first \\ should be a single or double backslash. You might have to try both variants.
The other ls syntax that might work is the following:
restic ls latest /\\server\Share/subfolder

The easiest way is probably to just run restic ls latest and use the paths exactly as printed there (you might have to escape backslashes though).

Thank you very much, for the information you gave me, I worked it out and here are the results. it took a bit long because the s3 server had some issues and was very hard to test not to confirm it was my syntax problem or s3 problem.
This is 100% Working
restic ls 7495c3e9be6b539533c912sdfds1b133e58e3102ac6e1651fa4977c5fbb83d0c05f  /\\server\Share --cache-dir cache
Now Regarding Restore, I followed similar method, asls Tried Methods follow below
I need help too, something in me doing is not right .
A)
restic restore 7495c3e9be6b539533c912sdfds1b133e58e3102ac6e1651fa4977c5fbb83d0c05f  --target C:\Users\Mypc\Desktop\test123  --include  //server/Share/sample  --cache-dir cache
B)
restic restore 7495c3e9be6b539533c912sdfds1b133e58e3102ac6e1651fa4977c5fbb83d0c05f  --target C:\Users\Mypc\Desktop\test123  --include  /\\server\Share/sample  --cache-dir cache
C)
restic restore 7495c3e9be6b539533c912sdfds1b133e58e3102ac6e1651fa4977c5fbb83d0c05f  --target C:\Users\Mypc\Desktop\test123  --include  latest/\\server\Share/sample  --cache-dir cache
D)
restic restore 7495c3e9be6b539533c912521b133e58e3102ac6e1651fa4977c5fbb83d0c05f  --target C:\Users\Mypc\Desktop\test123  --include  latest:/\\server\Share/sample  --cache-dir cache
E)
restic restore latest  --target C:\Users\Mypc\Desktop\test123  --include  latest:/\\server\Share/sample  --cache-dir cache
A, B,C,D and E , are not working
Thank you.

A, B,C,D F and G , are not working

None of those variants use the snapshot:subfolder syntax in the correct place and therefore cannot work.
Let's take a closer look at restic restore latest  --target C:\Users\Mypc\Desktop\test123  --include  latest:\server\Share/sample  --cache-dir cache:

latest: that's the snapshot id, and also the place where the snapshot:subfolder syntax would have to be used.
 --include  latest:\server\Share/sample:  this tells restore to only include files from the folder latest:\server\Share/sample which cannot work. If server\Share shows up as part of the parameter to --include then  it won't work.

What you want to use is something like the following:
restic restore latest:/\\server\Share/ --target C:\Users\Mypc\Desktop\test123  --include /sample  --cache-dir cache

I just gave it a try and the following pattern works (slightly simplified from my previous suggestion):
restic restore latest:/\\server\Share/ --target output

This seems to be an issue that affects ResticBrowser where restic ls latest / doesn't work as expected with UNC paths which means the GUI returns no results.
ResticBrowser and restic.exe won't show anything in the root path but specifying the UNC path does seem to work like other users mentioned: restic ls latest /\\host\share
Since backup paths are added to the metadata of the snapshot it saves us from guessing but it seems like restic should treat any instance of \** appearing at the start of a path like any other directory.


deserializing attribute set on server

Hi,
It looks to me that if attribute is not set during createFragment, and if later in persisting process server sets the attribute and returns it in json, that attribute is not deserialized.
I am still in debug phase so I am not 100% sure

I checked litle bit further, it is not deserializing even when I set attribute, server sends ne value for that attribute but it remains the same.
I am using ember 1.13.9 and ember-data 1.13.14

My error, the server was returning JSON with different names for fragments, fixed that and deserializing works fine

:+1:


Equivalent to --show-path in config file

Hello
First of all, huge thanks for this incredible work of yours!
I was about to start a very similar project and was amazed to find this gem ;-)
Is there a way to force a show's path when using the config file mode? Similar to the command line argument --show-path?

Bonjour
Thanks, it's always a pleasure re receive positive feedback.
Sure, I'll add it


Explicitily specify that "Response.add_etag" adds etag based on the "Response.get_data"

Nothing much, Just clarified werkzeug.Response.add_etag uses werkzeug.Response.get_data on it's docstring to make it less confusing with werkzeug.Response.set_etag, It's not much, But it is honest work :D

fixes #1948

Checklist:

[ ] Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
[x] Add or update relevant docs, in the docs folder and in code.
[ ] Add an entry in CHANGES.rst summarizing the change and linking to the issue.
[ ] Add .. versionchanged:: entries in any relevant code docs.
[x] Run pre-commit hooks and fix any issues.
[x] Run pytest and tox, no tests failed.

Thanks for looking at this. However, your suggested change makes less sense to me, it does not read naturally and seems to be restating what's already stated. "the response" refers to the current response object the method is called on. I tried to imagine a way to write this differently, but could not think of anything. Sorry this was confusing for you, but I don't have a better idea.

Thanks @davidism, The key element is the "Based on" part, The way I see it, both set_etag and add_etag, can add or set etag on the response, but one of them takes an argument which is the actual etag, while the otherone does the etag calculation based on the response.get_data, regardless of the etag you may wanna set!
just having them as set and add does not clarify that one of them gets calculated automatically, now, using words is not my best strength, so instead of continuing here, I'm gonna add this very same message on the mentioned issue and hope maybe someone comes up with better words to specify these 2 methods are different.


Springs.Element.Unjoin

Morning,
im working on a definition to unjoin elements that generated warnings when not join.
Im not sure why im getting null though

Hi Daniel,
Archilab's warnings nodes use a custom element object. You'll have to first pull the actual elements from that prior to using them with any of the existing nodes.

Ahhhh
I used WarningElement.iD then Select.ByElementId and of course... you we're right :)


Feature request : Force open option

Hi, I would like to ask considering adding "Force open" support for Pf2e system, but I think it can apply to more systems :
"Using your body, a lever, or some other tool, you attempt to forcefully open a door, window, container or heavy gate. With a high enough result, you can even smash through walls. Without a crowbar, prying something open takes a –2 item penalty to the Athletics check to Force Open.
Critical Success You open the door, window, container, or gate and can avoid damaging it in the process.
Success You break the door, window, container, or gate open, and the door, window, container, or gate gains the broken condition. If it’s especially sturdy, the GM might have it take damage but not be broken.
Critical Failure Your attempt jams the door, window, container, or gate shut, imposing a –2 circumstance penalty on future attempts to Force it Open."

Athletics DC per door/container
Check for crowbar to remove the malus.
Check for Pf2e 4 degrees of success and nat 1/20 and +10/-10 rules

A general force open interaction will be relativ easy to implement. I will try to add it in the next version. The Pf2e specific rules however are a bit more complex and will probably be added in a later release.

This feature has been added in v1.3.0. You will however have to add the crowbar bonus manually to the item settings of crowbars items. I will probably add a pack with custom items that already have these bonuses in one of the next releases. The critical success/failure system is also not implemented yet and will be added in the next release (unless bug fixes have te be prioritized).

Version 1.6.0 improved the compatibility with the Pf2e system, may be relevant to this request

I have added integration for MATT with v1.11.0 which should be capable of handling things like dealing damage to tokens on failure.


Missing rust visualizations.

Which OS: MacOS Mojave
Which VSCode version:  1.32.0
Which extension version: lldb 1.2.1
Which adapter type: classic
Which LLDB version: lldb-1<IP_ADDRESS> Swift-4.2
What is the problem and how did you get there:
This is my first time debugging rust with a debugger.  Watch expressions for rust types like Vec show raw data without visualizations.
My launch configuration: https://gitlab.com/szaver/sensorpi/blob/7c7ab62882d6b1c595c305ddbfb0b9246eb0817d/.vscode/launch.json
Debug output: https://gist.github.com/whmountains/aa6c01af4c8ac6d19eac4c73158864ff

Classic adapter + Swift-lldb is not going to decode Rust data types properly.
Please try adding "lldb.adapterType": "native" in settings.

Closing as I don't have time to test right now.


Do not error out with Gtk4

CC @TingPing Could you take a look at this?
This PR basically hides code behind ifs until make check stops erroring out when Gtk4 GIR is installed.
Fixes: #226

Oh, yay, thanks a lot Travis... :-(


*: update docs about reset task and relay log purge

What is changed, added or deleted? (Required)

update the FAQ about reset task
clarify the purge-expires config item

Which DM version(s) do your changes apply to? (Required)

[x] master (the latest development version, including v2.0 changes for now)
[ ] v1.0 (TiDB DM 1.0 versions)

What is the related PR or file link(s)?

This PR is translated from: https://github.com/pingcap/docs-dm/pull/103
Other reference link(s):

PTAL again @ran-huang

LGTM

@csuzhangxc PTAL

/merge

/merge


Direction of viruses

Viruses always go to the right when they hit a lot of mass. This doesn't happen in MultiOgar.
See this video at 0:57.

It's actually right. Math.PI / 2.

@NatsuTheGreat Oh, i meant right.

MultiOgar virus works exatly the same as on the video.
Virus split direction depends on direction of ejected mass.
So, if ejected mass was ejected from right to left, then virus will split from right to left, it doesn't depend on virus movement direction.

NatsuTheGreat: no, there is no Math.PI / 2. It's not the case.
And vanilla doesn't uses angles at all. Basically Math.PI / 2 is just Vector.X in vector arithmetic, it's usually used when vector length cannot be determined.

If you have video from vanilla where virus splits to the right from ejected mass which ejected to the left direction it looks like vanilla bug. It's not fair for gameplay.


Enhancement: Null Consumer/Consumer updates

When null consumer is used ...

dest existence check should be skipped
if possible the second argument (multifile mode at least) in the manifest format should be optional
if possible the second argument in single-file mode should be optional

Perhaps the consumer is responsible for determining if a file can be overwritten?

partially addressed with #120


Flutter platform Windows

Please consider supporting Flutter platform Windows

I would also like to know if Windows support is at least planned.

related to #330


Crash in ConnectionImpl::onMessageBeginBase

Description:
Envoy crashes with the supplied configuration file, and using tcpkali as a server.
I tested with Envoy trunk on macOS, using f95269d5f06da435d14162b14cde664edec95109.
Repro steps:
# Start tcpkali in listening mode, with a dummy reply:
$ tcpkali -T300 -l127.1:4444 --listen-mode=active -e1 'HTTP/1.1 200 OK\nContent-Length: 4\n\nnice\r\n' --dump-all

# Start Envoy with the included configuration, it will crash immediately:
$ envoy-static -c envoy-crash.json
[2018-05-09 16:16:50.817][49754746][info][main] source/server/server.cc:188] initializing epoch 0 (hot restart version=disabled)
[2018-05-09 16:16:50.819][49754746][info][main] source/server/server.cc:190] statically linked extensions:
[2018-05-09 16:16:50.819][49754746][info][main] source/server/server.cc:192]   access_loggers: envoy.file_access_log,envoy.http_grpc_access_log
[2018-05-09 16:16:50.819][49754746][info][main] source/server/server.cc:195]   filters.http: envoy.buffer,envoy.cors,envoy.ext_authz,envoy.fault,envoy.grpc_http1_bridge,envoy.grpc_json_transcoder,envoy.grpc_web,envoy.gzip,envoy.health_check,envoy.http_dynamo_filter,envoy.ip_tagging,envoy.lua,envoy.rate_limit,envoy.router,envoy.squash
[2018-05-09 16:16:50.819][49754746][info][main] source/server/server.cc:198]   filters.listener: envoy.listener.original_dst,envoy.listener.proxy_protocol,envoy.listener.tls_inspector
[2018-05-09 16:16:50.819][49754746][info][main] source/server/server.cc:201]   filters.network: envoy.client_ssl_auth,envoy.echo,envoy.ext_authz,envoy.http_connection_manager,envoy.mongo_proxy,envoy.ratelimit,envoy.redis_proxy,envoy.tcp_proxy
[2018-05-09 16:16:50.826][49754746][info][main] source/server/server.cc:203]   stat_sinks: envoy.dog_statsd,envoy.metrics_service,envoy.statsd
[2018-05-09 16:16:50.826][49754746][info][main] source/server/server.cc:205]   tracers: envoy.dynamic.ot,envoy.lightstep,envoy.zipkin
[2018-05-09 16:16:50.826][49754746][info][main] source/server/server.cc:208]   transport_sockets.downstream: raw_buffer,ssl
[2018-05-09 16:16:50.826][49754746][info][main] source/server/server.cc:211]   transport_sockets.upstream: raw_buffer,ssl
[2018-05-09 16:16:50.881][49754746][info][config] source/server/configuration_impl.cc:52] loading 1 listener(s)
[2018-05-09 16:16:50.900][49754746][info][config] source/server/configuration_impl.cc:92] loading tracing configuration
[2018-05-09 16:16:50.900][49754746][info][config] source/server/configuration_impl.cc:114] loading stats sink configuration
[2018-05-09 16:16:50.900][49754746][info][main] source/server/server.cc:387] starting main dispatch loop
[2018-05-09 16:16:50.901][49754746][info][upstream] source/common/upstream/cluster_manager_impl.cc:131] cm init: all clusters initialized
[2018-05-09 16:16:50.901][49754746][info][main] source/server/server.cc:371] all clusters initialized. initializing init manager
[2018-05-09 16:16:50.901][49754746][info][config] source/server/listener_manager_impl.cc:608] all dependencies initialized. starting workers
[2018-05-09 16:16:50.902][49754746][critical][assert] source/common/http/http1/codec_impl.cc:376] assert failure: !current_header_map_
[2018-05-09 16:16:50.902][49754746][critical][backtrace] bazel-out/darwin-fastbuild/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:114] Caught Abort trap: 6, suspect faulting address 0x7fff74b1fb6e
[2018-05-09 16:16:50.951][49754746][critical][backtrace] bazel-out/darwin-fastbuild/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:87] Backtrace obj<envoy-static> thr<0>:
[2018-05-09 16:16:50.951][49754746][critical][backtrace] bazel-out/darwin-fastbuild/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:99] thr<0> obj<envoy-static                        0x000000010416a7d6 _ZN8backward7details6unwindINS_14StackTraceImplINS_10system_tag10darwin_tagEE8callbackEEEmT_m>
[2018-05-09 16:16:50.951][49754746][critical][backtrace] bazel-out/darwin-fastbuild/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:105] thr<0> #0 0x10416a7d6:
[2018-05-09 16:16:50.951][49754746][critical][backtrace] bazel-out/darwin-fastbuild/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:99] thr<0> obj<envoy-static>
[2018-05-09 16:16:50.985][49754746][critical][backtrace] bazel-out/darwin-fastbuild/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:105] thr<0> #1 0x10416a345: backward::StackTraceImpl<backward::system_tag::darwin_tag>::load_here(unsigned long) + 101
[2018-05-09 16:16:50.985][49754746][critical][backtrace] bazel-out/darwin-fastbuild/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:105] thr<0> #2 0x10416a141: backward::StackTraceImpl<backward::system_tag::darwin_tag>::load_from(void*, unsigned long) + 49
[2018-05-09 16:16:50.985][49754746][critical][backtrace] bazel-out/darwin-fastbuild/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:105] thr<0> #3 0x10416869e: Envoy::BackwardsTrace::captureFrom(void*) + 46
[2018-05-09 16:16:50.985][49754746][critical][backtrace] bazel-out/darwin-fastbuild/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:105] thr<0> #4 0x10416855f: Envoy::SignalAction::sigHandler(int, __siginfo*, void*) + 143
[2018-05-09 16:16:51.087][49754746][critical][backtrace] bazel-out/darwin-fastbuild/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:110] end backtrace thread 0
Abort trap: 6

Config:
{
  "listeners": [
    {
      "address": "tcp://<IP_ADDRESS>:1111",
      "filters": [
        {
          "type": "read",
          "name": "http_connection_manager",
          "config": {
            "codec_type": "http1",
            "stat_prefix": "mycluster",
            "route_config": {
              "virtual_hosts": [
                {
                  "name": "mycluster",
                  "domains": ["*"],
                  "routes": [
                    {
                      "prefix": "/",
                      "use_websocket": true,
                      "cluster": "mycluster"
                    }
                  ]
                }
              ]
            },
            "filters": [
              {
                "type": "decoder",
                "name": "router",
                "config": {}
              }
            ]
          }
        }
      ]
    }
  ],
  "admin": {
    "access_log_path": "/dev/null",
    "address": "tcp://<IP_ADDRESS>:8001"
  },
  "cluster_manager": {
    "clusters": [
      {
        "name": "mycluster",
        "connect_timeout_ms": 1000,
        "type": "strict_dns",
        "lb_type": "round_robin",
        "health_check": {
          "type": "http",
          "timeout_ms": 1000,
          "interval_ms": 5000,
          "unhealthy_threshold": 1,
          "healthy_threshold": 3,
          "path": "/health",
          "service_name": "my-service-name"
        },
        "hosts": [ { "url": "tcp://<IP_ADDRESS>:4444" } ]
      }
    ]
  }
}

Call Stack:
[2018-05-09 16:16:50.901][49754746][info][config] source/server/listener_manager_impl.cc:608] all dependencies initialized. starting workers
[2018-05-09 16:16:50.902][49754746][critical][assert] source/common/http/http1/codec_impl.cc:376] assert failure: !current_header_map_
[2018-05-09 16:16:50.902][49754746][critical][backtrace] bazel-out/darwin-fastbuild/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:114] Caught Abort trap: 6, suspect faulting address 0x7fff74b1fb6e
[2018-05-09 16:16:50.951][49754746][critical][backtrace] bazel-out/darwin-fastbuild/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:87] Backtrace obj<envoy-static> thr<0>:
[2018-05-09 16:16:50.951][49754746][critical][backtrace] bazel-out/darwin-fastbuild/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:99] thr<0> obj<envoy-static                        0x000000010416a7d6 _ZN8backward7details6unwindINS_14StackTraceImplINS_10system_tag10darwin_tagEE8callbackEEEmT_m>
[2018-05-09 16:16:50.951][49754746][critical][backtrace] bazel-out/darwin-fastbuild/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:105] thr<0> #0 0x10416a7d6:
[2018-05-09 16:16:50.951][49754746][critical][backtrace] bazel-out/darwin-fastbuild/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:99] thr<0> obj<envoy-static>
[2018-05-09 16:16:50.985][49754746][critical][backtrace] bazel-out/darwin-fastbuild/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:105] thr<0> #1 0x10416a345: backward::StackTraceImpl<backward::system_tag::darwin_tag>::load_here(unsigned long) + 101
[2018-05-09 16:16:50.985][49754746][critical][backtrace] bazel-out/darwin-fastbuild/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:105] thr<0> #2 0x10416a141: backward::StackTraceImpl<backward::system_tag::darwin_tag>::load_from(void*, unsigned long) + 49
[2018-05-09 16:16:50.985][49754746][critical][backtrace] bazel-out/darwin-fastbuild/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:105] thr<0> #3 0x10416869e: Envoy::BackwardsTrace::captureFrom(void*) + 46
[2018-05-09 16:16:50.985][49754746][critical][backtrace] bazel-out/darwin-fastbuild/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:105] thr<0> #4 0x10416855f: Envoy::SignalAction::sigHandler(int, __siginfo*, void*) + 143
[2018-05-09 16:16:51.087][49754746][critical][backtrace] bazel-out/darwin-fastbuild/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:110] end backtrace thread 0
Abort trap: 6

@ggreenway

This is not websocket-specific. I deleted the "use_websocket" line from the config and get the same result.

#1  0x00007ffff711202a in __GI_abort () at abort.c:89
#2  0x0000000000b9bc90 in Envoy::Http::Http1::ConnectionImpl::onMessageBeginBase (this=0x2548fc8) at source/common/http/http1/codec_impl.cc:376
#3  0x0000000000b9ab22 in Envoy::Http::Http1::ConnectionImpl::<lambda(http_parser*)>::operator()(http_parser *) const (__closure=0x0, parser=0x2548fd8) at source/common/http/http1/codec_impl.cc:246
#4  0x0000000000b9ab47 in Envoy::Http::Http1::ConnectionImpl::<lambda(http_parser*)>::_FUN(http_parser *) () at source/common/http/http1/codec_impl.cc:248
#5  0x0000000000ba343d in http_parser_execute (parser=0x2548fd8, settings=0x1b6ad00 <Envoy::Http::Http1::ConnectionImpl::settings_>, data=0x28e6c30 "HTTP/1.1 200 OK\nContent-Length: 4\n\nnice\r\n", len=41)
    at external/com_github_nodejs_http_parser/http_parser.c:775
#6  0x0000000000b9b939 in Envoy::Http::Http1::ConnectionImpl::dispatchSlice (this=0x2548fc8, slice=0x28e6c30 "HTTP/1.1 200 OK\nContent-Length: 4\n\nnice\r\n", len=41)
    at source/common/http/http1/codec_impl.cc:327
#7  0x0000000000b9b80d in Envoy::Http::Http1::ConnectionImpl::dispatch (this=0x2548fc8, data=...) at source/common/http/http1/codec_impl.cc:316
#8  0x0000000000a9e8b1 in Envoy::Http::CodecClient::onData (this=0x25fec60, data=...) at source/common/http/codec_client.cc:115
#9  0x0000000000aa003c in Envoy::Http::CodecClient::CodecReadFilter::onData (this=0x254af00, data=...)
    at bazel-out/k8-dbg/bin/source/common/http/_virtual_includes/codec_client_lib/common/http/codec_client.h:160
#10 0x000000000084d967 in Envoy::Network::FilterManagerImpl::onContinueReading (this=0x2708018, filter=0x0) at source/common/network/filter_manager_impl.cc:56
#11 0x000000000084d9fe in Envoy::Network::FilterManagerImpl::onRead (this=0x2708018) at source/common/network/filter_manager_impl.cc:66
#12 0x0000000000844e86 in Envoy::Network::ConnectionImpl::onRead (this=0x2708000, read_buffer_size=41) at source/common/network/connection_impl.cc:213
#13 0x0000000000845cff in Envoy::Network::ConnectionImpl::onReadReady (this=0x2708000) at source/common/network/connection_impl.cc:441
#14 0x0000000000845b97 in Envoy::Network::ConnectionImpl::onFileEvent (this=0x2708000, events=3) at source/common/network/connection_impl.cc:417
#15 0x00000000008435bb in Envoy::Network::ConnectionImpl::ConnectionImpl(Envoy::Event::Dispatcher&, std::unique_ptr<Envoy::Network::ConnectionSocket, std::default_delete<Envoy::Network::ConnectionSocket> >&&, std::unique_ptr<Envoy::Network::TransportSocket, std::default_delete<Envoy::Network::TransportSocket> >&&, bool)::{lambda(unsigned int)#3}::operator()(unsigned int) const ()
    at source/common/network/connection_impl.cc:64
#16 0x000000000084737c in std::_Function_handler<void(unsigned int), Envoy::Network::ConnectionImpl::ConnectionImpl(Envoy::Event::Dispatcher&, Envoy::Network::ConnectionSocketPtr&&, Envoy::Network::TransportSocketPtr&&, bool)::<lambda(uint32_t)> >::_M_invoke(const std::_Any_data &, <unknown type in /tmp/_bazel_ggreenway/b9fd27fba8ca60f63bd77691369bf22f/execroot/envoy/bazel-out/k8-dbg/bin/source/exe/envoy-static, CU 0x3c74d2c, DIE 0x3cd45c4>) (__functor=...,
    __args#0=<unknown type in /tmp/_bazel_ggreenway/b9fd27fba8ca60f63bd77691369bf22f/execroot/envoy/bazel-out/k8-dbg/bin/source/exe/envoy-static, CU 0x3c74d2c, DIE 0x3cd45c4>)
    at /usr/include/c++/5/functional:1871
#17 0x000000000083a68a in std::function<void (unsigned int)>::operator()(unsigned int) const (this=0x26a6988, __args#0=3) at /usr/include/c++/5/functional:2267
#18 0x00000000008396a8 in Envoy::Event::FileEventImpl::<lambda(int, short int, void*)>::operator()(int, short, void *) const (__closure=0x0, what=38, arg=0x26a6900)
    at source/common/event/file_event_impl.cc:60
#19 0x00000000008396d8 in Envoy::Event::FileEventImpl::<lambda(int, short int, void*)>::_FUN(int, short, void *) () at source/common/event/file_event_impl.cc:61
#20 0x0000000000dd5d52 in event_persist_closure (ev=<optimized out>, base=0x25a62c0) at event.c:1580
#21 event_process_active_single_queue (base=base@entry=0x25a62c0, max_to_process=max_to_process@entry=2147483647, endtime=endtime@entry=0x0, activeq=<optimized out>) at event.c:1639
#22 0x0000000000dd64af in event_process_active (base=0x25a62c0) at event.c:1738
#23 event_base_loop (base=0x25a62c0, flags=0) at event.c:1961
#24 0x000000000083419e in Envoy::Event::DispatcherImpl::run (this=0x25583c0, type=Envoy::Event::Dispatcher::RunType::Block) at source/common/event/dispatcher_impl.cc:161
#25 0x00000000007d9ff2 in Envoy::Server::InstanceImpl::run (this=0x25cf340) at source/server/server.cc:405
#26 0x0000000000433a10 in Envoy::MainCommonBase::run (this=0x2590998) at source/exe/main_common.cc:83
#27 0x0000000000420860 in Envoy::MainCommon::run (this=0x2590500) at bazel-out/k8-dbg/bin/source/exe/_virtual_includes/envoy_main_common_lib/exe/main_common.h:44
#28 0x0000000000419d91 in main (argc=3, argv=0x7fffffffe408) at source/exe/main.cc:30

Looking at a packet capture, an HTTP response was sent BEFORE the HTTP request for the health check. Basically as soon as the connection was established, a response was sent.
pcap.tar.gz

+1 - we absolutely need to handle this without crashing.  I'm curious if the stray data came in early on a preexisting connection if the fix in #2871 would have caught it but either way we can't rely on the data to

FWIW, I have a repeater for this using https://github.com/envoyproxy/envoy/pull/3338 and a corpus that local fuzzing discovered.

I'm also seeing this with the same stack trace. I see a read error in my trace-level log that isn't mentioned above, so figured I'd post my log as well:
[2018-05-29 21:29:06.548][120239][debug][main] external/envoy/source/server/server.cc:131] flushing stats
[2018-05-29 21:29:06.616][120239][trace][connection] external/envoy/source/common/network/connection_impl.cc:385] [C1] socket event: 3
[2018-05-29 21:29:06.616][120239][trace][connection] external/envoy/source/common/network/connection_impl.cc:453] [C1] write ready
[2018-05-29 21:29:06.616][120239][trace][connection] external/envoy/source/common/network/connection_impl.cc:423] [C1] read ready
[2018-05-29 21:29:06.616][120239][trace][connection] external/envoy/source/common/network/raw_buffer_socket.cc:25] [C1] read returns: 2
[2018-05-29 21:29:06.616][120239][trace][connection] external/envoy/source/common/network/raw_buffer_socket.cc:25] [C1] read returns: -1
[2018-05-29 21:29:06.616][120239][trace][connection] external/envoy/source/common/network/raw_buffer_socket.cc:33] [C1] read error: 11
[2018-05-29 21:29:06.616][120239][trace][http] external/envoy/source/common/http/http1/codec_impl.cc:305] [C1] parsing 2 bytes
[2018-05-29 21:29:06.616][120239][critical][assert] external/envoy/source/common/http/http1/codec_impl.cc:376] assert failure: !current_header_map_
[2018-05-29 21:29:06.616][120239][critical][backtrace] bazel-out/k8-fastbuild/bin/external/envoy/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:114] Caught Aborted, suspect faulting address 0x9c690001d5af
[2018-05-29 21:29:06.617][120239][critical] Backtrace (most recent call first) from thread 0:
  #1 ?? ??:0
  #2 ?? ??:0
  #3
  #4 Envoy::Http::Http1::ConnectionImpl::onMessageBeginBase() at codec_impl.cc:376 (discriminator 4)
  #5 Envoy::Http::Http1::ConnectionImpl::{lambda(http_parser*)#1}::operator()(http_parser*) const at codec_impl.cc:246
  #6 Envoy::Http::Http1::ConnectionImpl::{lambda(http_parser*)#1}::_FUN(http_parser*) at codec_impl.cc:248
  #7 http_parser_execute at http_parser.c:775 (discriminator 3)
  #8 Envoy::Http::Http1::ConnectionImpl::dispatchSlice(char const*, unsigned long) at codec_impl.cc:327
  #9 Envoy::Http::Http1::ConnectionImpl::dispatch(Envoy::Buffer::Instance&) at codec_impl.cc:316 (discriminator 2)
  #10 Envoy::Http::CodecClient::onData(Envoy::Buffer::Instance&) at codec_client.cc:115
  #11 Envoy::Http::CodecClient::CodecReadFilter::onData(Envoy::Buffer::Instance&, bool) at codec_client.h:160
  #12 Envoy::Network::FilterManagerImpl::onContinueReading(Envoy::Network::FilterManagerImpl::ActiveReadFilter*) at filter_manager_impl.cc:56
  #13 Envoy::Network::FilterManagerImpl::onRead() at filter_manager_impl.cc:66
  #14 Envoy::Network::ConnectionImpl::onRead(unsigned long) at connection_impl.cc:214
  #15 Envoy::Network::ConnectionImpl::onReadReady() at connection_impl.cc:442
  #16 Envoy::Network::ConnectionImpl::onFileEvent(unsigned int) at connection_impl.cc:418
  #17 Envoy::Network::ConnectionImpl::ConnectionImpl(Envoy::Event::Dispatcher&, std::unique_ptr<Envoy::Network::ConnectionSocket, std::default_delete<Envoy::Network::ConnectionSocket> >&&, std::unique_ptr<Envoy::Network::TransportSocket, std::default_delete<Envoy::Network::TransportSocket> >&&, bool)::{lambda(unsigned int)#3}::operator()(unsigned int) const at connection_impl.cc:65
  #18 std::_Function_handler<void (unsigned int), Envoy::Network::ConnectionImpl::ConnectionImpl(Envoy::Event::Dispatcher&, std::unique_ptr<Envoy::Network::ConnectionSocket, std::default_delete<Envoy::Network::ConnectionSocket> >&&, std::unique_ptr<Envoy::Network::TransportSocket, std::default_delete<Envoy::Network::TransportSocket> >&&, bool)::{lambda(unsigned int)#3}>::_M_invoke(std::_Any_data const&, unsigned int&&) at std_function.h:316
  #19 std::function<void (unsigned int)>::operator()(unsigned int) const at std_function.h:706
  #20 Envoy::Event::FileEventImpl::assignEvents(unsigned int)::{lambda(int, short, void*)#1}::operator()(int, short, void*) const at file_event_impl.cc:60
  #21 Envoy::Event::FileEventImpl::assignEvents(unsigned int)::{lambda(int, short, void*)#1}::_FUN(int, short, void*) at file_event_impl.cc:61
  #22 event_persist_closure at event.c:1580
  #23  (inlined by) event_process_active_single_queue at event.c:1639
  #24 event_process_active at event.c:1738
  #25  (inlined by) event_base_loop at event.c:1961
  #26 Envoy::Event::DispatcherImpl::run(Envoy::Event::Dispatcher::RunType) at dispatcher_impl.cc:161 (discriminator 4)
  #27 Envoy::Server::InstanceImpl::run() at server.cc:390
  #28 Envoy::MainCommonBase::run() at main_common.cc:83
  #29 Envoy::MainCommon::run() at main_common.h:44
  #30 main at main.cc:30 (discriminator 1)
  #31
  #32 ?? ??:0
  #33
  #34 _start at ??:?
  #35

I've been looking at this for a bit, and it's not as straightforward as I thought. Also, I think the fuzz test failure is slightly different from the original issue. I will figure this out fully tomorrow.

I've opened https://github.com/nodejs/http-parser/pull/432 to fix what I think is an http-parser bug. I will also test the original websocket issue to see if it's the same issue.

I just confirmed the original issue is the same as the fuzz test issue. I will wait to see what upstream says about my fix.

Nice, thanks Matt!

Yeah, thanks @mattklein123 for investigating and submitting the upstream fix. :+1:
Should we poke around a bit more on envoy's side though? It seems unlikely that my super-simple golang HTTP server is responding with a CR/LF before the HTTP header. Could there be a reused connection that needs to flush out trailing CR/LF before starting the next request?

@llchan yes, that's exactly what is happening. My upstream fix will flush CRL/LF.

I guess my question is more like, how did it even get into that state where there's an extra CR/LF sitting around? Shouldn't the Content-Length of the previous response give us the right size to read off? Is there some streaming parser (e.g. JSON) that consumes the data but not the newline after it?

I have no idea, I didn't dig that deeply. AFAICT the parser should be eating extra CR/LF between responses and that's what I fixed it to do.

Now that the http-parser PR is merged, what's the game plan? Do we need to wait for a tagged http-parser release, or can we point at the latest master?

@llchan it has not been merged. Please ping the PR there and try to get them to merge it.

Derp, my bad, misread the notification. It got the second approval it was awaiting though, so hopefully they actually merge it soon. I'm seeing many crashes a day from this so just trying to keep things moving.

Thanks for the persistence in getting this in!


finish event

The function passed as a second parameter to upload() is triggered before all the rowHandler calls are complete. Is there an event that signals when all rows have been processed? Or maybe a way to get a row count so I can add a conditional statement for when that count is reached?

I passed an async function to rowHandler and didn't get any error, so I assumed that was supported. Looks like that is not the case (hence the callback function triggering before the promises were resolved). I refactored my code to perform the async steps after CSV parsing was complete.


scrollToIndex with animationMilliseconds doesn't animate

Great module!
Tried to use scrollToIndex with custom value for animationMilliseconds. Didn't animate as expected (at all).
Checked the source and found the retry retryIfNeeded() fires the method with animationMilliseconds=0.
https://github.com/rintoj/angular2-virtual-scroll/blob/78bdd79ba79a0efc9ff2aa556f7109da2c2908da/src/virtual-scroll.ts#L329
Why is that?
If I change to the animationMilliseconds variable, it works as expected.

It works correctly on all the demos at http://rintoj.github.io/angular2-virtual-scroll. I believe the component code is correct & it's something wrong with your app. Please submit a stackblitz if you need help troubleshooting.
If you look at the sourcecode, scrollToIndex calls scrollToIndex_internal 2x, the retry portion is hard-coded to 0, but the original call uses the animationMilliseconds parameter.
The retry is used in case the 1st auto-scroll went to the wrong location. This can happen if you use [enableUnequalChildrenSizes]="true" because the child items aren't pre-measured, they're estimated & measured in realtime while scrolling. The estimates are usually pretty close & the retry should instantly snap to the correct place at the end of the animation. If we used the the animationMilliseconds parameter during the retry the total animation would take 2x as long as intended.

Closing since I haven't heard back from the original poster & it seems like user error. Please re-open if you continue to experience issues.

I had the same problem. In my case, another dependency was using Tween.js v16, while ngx-virtual-scroller uses v17. The build process only included one copy (v16) of the library, and there's a slight change on its onUpdate() callback. I managed to work around this issue by updating this other dependency to get rid of Tween.js v16.


Setup Continuous Delivery

Summary
As we discussed on Discord channel on Nov 6th, this PR adds appropriate hooks to CircleCI in order to deploy successful builds (on master branch) to npm using tag that has been assigned to the latest commit.
This is how deployment process should look like:
Once you want to deploy, push a new tag to master. That will trigger a deployment script on CI. According to CircleCI documentation, the best way is to use
npm version x.y.z

in order to update package version and create git tag.  Then, you can push your code using
git push --follow-tags

After successful build, a new version will be released.

Test plan
Not sure if there is a way to properly test it before the merge. I think the only way is to merge it in, setup NPM_TOKEN env variable and try to create a new version by running build on CI. Please, let me know if you see alternative scenarios.

That's awesome! Thanks a lot for working on this, this will allow us move the npm publish step from our internal infra to GH-first, something we've wanted to do for a long time.
Unfortunately, we can't npm publish directly the content of the repo, since we need to run a build step before to remove the flow annotations from the code.
The (super-hacky)™ way that I've been using lately to publish to npm from the github repo is the following:

Run yarn to install the needed dev-dependencies.
Run yarn run build, to create the publish-ready files (they're stored in packages/metro-bundler/build).
rm -fr packages/metro-bundler/src; mv packages/metro-bundler/build packages/metro-bundler/src (to replace the src content with the built code, since the "main" field in our package.json points to src/ ).
cd packages/metro-bundler; npm publish (we need to publish from that sub-folder).
git checkout .; git clean -dxf (to clean-up the repo).

As you can see, this process is terrible, so if you have any suggestion to improve it will be greatly appreciated :) In the meantime we could have an npm script that does this process which can be run using yarn run publish from circleCI.

Hi @rafeca!
Thanks for the feedback! I have a question regarding №3: any particular reason why you want to point to src instead of build? Is it done so to make development process easier or something?
In the meantime, I'll make a script that reflects your algorithm above so we can start from something :)

Thanks for the feedback! I have a question regarding №3: any particular reason why you want to point to src instead of build? Is it done so to make development process easier or something?

This is because internally at FB people don't use the npm version of metro. Instead, its master version is required directly from our monorepo (with require hooks to remove flow annotations)

I've updated PR according to your feedback and discussion that took place in Discord.
Looking forward for your feedback! 🙌

Can you take another glance, @rafeca?

Should be good now 😉

Niceeeee! I've just imported the PR to phabricator, to land it from there

YISSS, we got the CircleCI builds. Thanks a lot for doing this

Also, check out our config in Yarn to see how to enable macOS builds too: https://github.com/yarnpkg/yarn/blob/master/.circleci/config.yml

Also looks like you need a rebase :)

Thanks for your feedback, @BYK!
Should be adjusted now.

Any updates on this, @rafeca?

@Kureev I'm importing the PR to phabricator right now to land it :)
Next step is getting the CI tests passing, @cpojer offered to fix them 😄

"offered" 😆


Add package.json

Just pushing some old changes I had made locally.

@m-cat I haven't merged yet because the PR is quite stale, do these still apply?

Yep thanks!


tests.nixpkgs-check-by-name: Fix ratchet checks in certain cases

Description of changes
This fixes an odd problem where changing an attribute to use e.g. callPackage suddenly requires moving it to pkgs/by-name, when that shouldn't have been required.
See https://github.com/NixOS/nixpkgs/pull/282448 and the CI run: https://github.com/NixOS/nixpkgs/actions/runs/7618046790/job/20748392177
Ping @hzeller
This work is sponsored by Antithesis and Tweag :sparkles:
Things done

[x] Added test cases for the new behavior
[x] Tidy code

Add a :+1: reaction to pull requests you find important.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/tweag-nix-dev-update-53/39180/1


Predictive Analytics article

Note - This article needs an author and date update, and featured image before publishing.

Please add 2 Tweetable quotes.

Tweetable quotes and main image are now included.


feat: UI multi contracts per pipeline

This implements the Mockup designs referenced in  AET-348 , AET-349
Allowing a user to create multiple contracts displayed as tabs within a  pipeline with individual mapping validations based on the same input.
Also gets webpack working again with live and hot reloads
NOTE:
Tasks outstanding:

Contract revalidation on input change

@sabeen some styling updates are needed, especially around read-only pipelines and contracts
Related JIRA Ticket:
AET-352

Could you remove the VERSION and REVISION files? :grimacing:

Shouldn't this be create passthrough CONTRACT?

Can you take another look @obdulia-losantos @sabeen ?


Mouse over is not working correctly on city banner

If you open the city panel, the worker hexes are colored green/red to indicate locked or not. This coloring is not shown outside the city view on mouse over (unless you open/close the city first). Clicking a unit breaks it again.
Screenshots
If applicable, add screenshots to help explain your problem.
General informations

OS: [e.g. iOS]
Win 10
Version [e.g. <IP_ADDRESS>6]
Latest Civ (all DLCs except this years new ones)
Expansion [e.g. None, Rise and Fall]
All
Other mods [e.g. YnAMP]
Free Walls for City States, Constant Brightness (forget the name)

Save game and logs
Please attach if you can your save game and the logs. You can find them in ..\documents\my games\sid meier's civilization vi\ on windows or /Users/[user]/Library/Application Support/Sid Meier's Civilization VI/ on Mac OS.
Additional context
This has been mentioned in discussions but no issue was open.

EDIT: Actually this is how it behaves in my pre-2020 version so this is not a regression. Not sure if the behavior is a bug or not at this point.

I am confused.

Mouse hover, When you mouse hover over a banner then some hexes are colored and it also shows the culture border growth.
City view. When you enter the city view, then you see the same coloring plus citizen icons, buy next tile, etc.
What's the issue?

The 'feature' I am talking about is in the city view it shows locked and unlocked citizens by coloring the tiles green or red. When you are outside the city view if you mouse over the banner that same feature shows on the map. This only works after just leaving the city. If you focus a unit then hover does nothing until you enter a city and exit. Then again you can mouse over cities to see where unlocked workers are. I think it always shows the worker icons but I find them a little harder to see. Make sense?

Yup, much more sense :)
However from what I see in the game, you don't need to go into the city view again. Just unselect a unit. This is how it works for me (xp2 ruleset).
So, it boils down to the following: when you mouse hover then 3 things are displayed (yields, colors, border) but when a unit is selected then only 2 things are displayed (yields and border). Colors are missing.
I assume atm that city view is ok, no problems there.

I checked the code and it seems that this is not a bug but actually a fix for a problem with lenses. There is a comment from authors:
-- Fix for lens being shown when other lenses are on.
-- Don't show this lens if any unit is selected.
-- This prevents the need to check if every lens is on or not, like builder, religious lens.
I suppose it is like this because those color are actually handled by More Lenses mod, not CQUI itself. CQUI adds yielda and border growth and they don't interfere with lenses. However, if a unit is selected (builder, religion, scout, etc.), a lens can be put on and it clearly conflicts with the citizen mgmt colors.

The root cause of the problem is that there are approx. 60 lens layers and the only function that checks which are active is UILens.IsLensActive() and it requires a specific layer id. If there was a function IsAnyLensActive() then this could be used instead of checking if a unit is selected.

Un-focusing the unit works and now that I know that it's not worth 'fixing' this it sounds like. Closing this.


Box2dLights support

General list of things needs to be done:

[ ] LightComponent
[ ] Runtime systems
[ ] Light settings dialog

[ ] SceneDeserializer: bump version code and handle null light settings data

[ ] Lighting switch button on toolbar
[ ] Creating point light
[ ] Creating cone light

Hi!
I found that i really need this support for my project. It will be really cool if you solve this.

Sorry, this is not going to happen. VisEditor is deprecated now. Some more info.


Set delay for capture of automatic screenshot

I have the problem that the automatic screenshot is always way too late. Is it possible to change the timing?

Yes check the mining section of the settings. There is a delay setting.

I already set the setting "Screenshot capture delay" in the Streaming Video section to 0 but it is still delayed by several seconds. I only have this issue in on Android. I don't see any setting in the Mining section that affects screenshot delay, what is it called?

The one you changed is the right one. But is it happening for local or streaming video?

Local video

For local videos the screenshot taken will be the frame on the screen at the time of mining. So you will have to manually adjust accordingly.


Blog Art: Role Base Access Blog

Related Issue
No response
Description
Considerations:

Where will the image be displayed/shared, product? blog post? social media? presentation? website?

Blog Post
Title: "Role-Based Access for your Node-RED applications"
Reference content:
Role-Based Access for your Node-RED applications
Inspirations:

Hi @gdziuba I just pushed it to the PR

@Yndira-E Thank you.


Adding support for metric attributes and events to fsoc melt model

Description
Adding support in fsoc melt model for:
Metric Attributes
Events
Type of Change

[X] New Feature

Codecov Report

Merging #64 (4dd3e01) into main (a98febf) will not change coverage.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@           Coverage Diff           @@
##             main      #64   +/-   ##
=======================================
  Coverage   32.87%   32.87%
=======================================
  Files          27       27
  Lines        3510     3510
=======================================
  Hits         1154     1154
  Misses       2265     2265
  Partials       91       91

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.