adc_continuous_read returning ESP_ERR_TIMEOUT (IDFGH-10857)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[x] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.
v5.0.3
Operating System used.
Linux
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
None
Development Kit.
esp32-s3-wroom-1
Power Supply used.
External 5V
What is the expected behavior?
adc_continuous_read is quite easy (80% possibility) to return ESP_ERR_TIMEOUT
What is the actual behavior?
adc_continuous_read is quite easy (80% possibility) to always return ESP_ERR_TIMEOUT (conv_frame_size set to 512), after power on reset, and s_adc_dma_intr is then never being called.
This occurs when running v5.0.3, but never occurs on v5.0.2.
I checked the history, seems this bug was introduced by commit 5da5e1801b and d8ee45ce08.
Wish you guys can confirm this.
I tried below patch, and seems can fix:
diff --git a/components/esp_adc/adc_continuous.c b/components/esp_adc/adc_continuous.c
index 643dfef..ed1f760 100644
--- a/components/esp_adc/adc_continuous.c
+++ b/components/esp_adc/adc_continuous.c
@@ -355,6 +355,11 @@ static IRAM_ATTR bool s_adc_dma_intr(adc_continuous_ctx_t *adc_digi_ctx)
         }
     }

+    if (status == ADC_HAL_DMA_DESC_NULL) {
+        //start next turns of dma operation
+        adc_hal_digi_start(&adc_digi_ctx->hal, adc_digi_ctx->rx_dma_buf);
+    }
+
     return need_yield;
 }

diff --git a/components/hal/adc_hal.c b/components/hal/adc_hal.c
index 3633816..2051ce6 100644
--- a/components/hal/adc_hal.c
+++ b/components/hal/adc_hal.c
@@ -238,7 +238,6 @@ static void adc_hal_digi_dma_link_descriptors(dma_descriptor_t *desc, uint8_t *d
     HAL_ASSERT(((uint32_t)data_buf % 4) == 0);
     HAL_ASSERT((per_eof_size % 4) == 0);
     uint32_t n = 0;
-    dma_descriptor_t *desc_head = desc;

     while (eof_num--) {
         uint32_t eof_size = per_eof_size;
@@ -262,7 +261,7 @@ static void adc_hal_digi_dma_link_descriptors(dma_descriptor_t *desc, uint8_t *d
             n++;
         }
     }
-    desc[n-1].next = desc_head;
+    desc[n-1].next = NULL;
 }

 void adc_hal_digi_start(adc_hal_dma_ctx_t *hal, uint8_t *data_buf)

Steps to reproduce.
running continuous_read_main.c
Debug Logs.
No response
More Information.
No response

I re-checked the code and did some testings, and found out it's because the dma interrupt stops generating during heavy load. I created a PR, it works fine for me, atleat now. Could you help to review it?

Hello, I have the same problem, what is the cause of this problem?

I re-checked the code and did some testings, and found out it's because the dma interrupt stops generating during heavy load. I created a PR, it works fine for me, atleat now. Could you help to review it?
A PR with similar changes have been accepted before. Sorry for the late reply.

Hello, I have the same problem, what is the cause of this problem?

You may upgrade to use a newer version.

A PR with similar changes have been accepted before. Sorry for the late reply.

You did not ever read the PR, right? This PR is based on the one you referenced.
Issue can still be reproduced by applying below patch to idf v5.0.4:
--- a/examples/peripherals/adc/continuous_read/main/continuous_read_main.c
+++ b/examples/peripherals/adc/continuous_read/main/continuous_read_main.c
@@ -12,6 +12,7 @@
 #include "freertos/task.h"
 #include "freertos/semphr.h"
 #include "esp_adc/adc_continuous.h"
+#include "nvs_flash.h"

 #define EXAMPLE_READ_LEN   256
 #define EXAMPLE_ADC_CONV_MODE           ADC_CONV_SINGLE_UNIT_1
@@ -111,6 +112,14 @@ void app_main(void)
     ESP_ERROR_CHECK(adc_continuous_register_event_callbacks(handle, &cbs, NULL));
     ESP_ERROR_CHECK(adc_continuous_start(handle));

+    vTaskDelay(100);
+    ret = nvs_flash_init();
+    if (ret == ESP_ERR_NVS_NO_FREE_PAGES || ret == ESP_ERR_NVS_NEW_VERSION_FOUND) {
+      ESP_ERROR_CHECK(nvs_flash_erase());
+      ret = nvs_flash_init();
+    }
+    nvs_flash_erase_partition("nvs_1");
+
     while(1) {

         /**

nvs_1 is something like this in partiton.csv:
nvs_1,   data, nvs,             0x1f8000,      32k,

If the PR was merged then why do I still have this problem?
I have esp-idf v5.1.2.
For me this problem appeared without me changing anything in my code.
I have a spiffs file and in a while loop I read an adc chunk and write it to the file.
I ran this code plenty of times, only changing code that happens after the while loop.
And one of the times I ran the code and got this error.
After that I consistently get this error every time I run the code.
And the thing that fixed it was either not writing to the file or reformatting the spiffs partition once and then it works every time
The partition was mostly empty when the error happened so I don't think it was caused by it being full.
Any ideas why this is happening.
Thanks in advance


<Popover.Close /> and <Form.Submit /> don't work when nested.

Bug report
Current Behavior
Mouse-clicking the result of nesting <Form.Submit /> inside a <Popover.Close asChild /> will close the popover but not submit the form. You get the same behaviour (popover closes but form doesn't submit) even if you nest <Popover.Close /> inside <Form.Submit asChild />.
On the other hand, pressing Enter will submit the form but not close the popover if you nest <Form.Submit /> inside a <Popover.Close asChild />. The reverse nesting will only close the popover when pressing Enter.
Expected behavior
Would expect both the form to be submitted and the popover to close regardless of whether the user clicks the nested button or presses Enter and regardless of which component is nested in the other.
Reproducible example
CodeSandbox minimal reproducible example
import * as React from "react";
import * as Form from '@radix-ui/react-form'
import * as Popover from '@radix-ui/react-popover'

export function App() {

  const handleSubmit = (e: React.FormEvent) => {
    e.preventDefault()
    alert("submitting!")
  }

  return (
    <Popover.Root>
      <Popover.Trigger>Open Sesame</Popover.Trigger>
      <Popover.Content>
        <Form.Root onSubmit={handleSubmit}>
          <Form.Field name="form">
            <Form.Control />
          </Form.Field>
          <Popover.Close asChild>
            <Form.Submit>Submit</Form.Submit>
          </Popover.Close>
        </Form.Root>
      </Popover.Content>
    </Popover.Root>
  )
}

Suggested solution
None, but happy to work on a solution if help is needed.
Additional context
One can solve this problem by controlling the open state of <Popover /> manually, but my sense is they should play nicely together out-of-the-box.
Your environment

Software
Name(s)
Version

Radix Package(s)
@radix-ui/react-form
0.0.3

React
n/a
18.2

Browser
Chrome
118.0.5993.70

Assistive tech

Node
n/a

npm/yarn

Operating System

Probably because Form.Submit is being unmounted causing onSubmit to never happen. I think the right way to handle this is as you are already doing, controlling the open and close state when the submit is finished

If it's true that Form.Submit is being unmounted, then wouldn't that also apply to a <button> as in this small example?
It seems like the button is able to handle the click before the popover unmounts it, but correct me if I'm misinterpreting what you're saying.

If it's true that Form.Submit is being unmounted

sorry, I meant Form.Root

To add one more toy example, when you add the onClick handler explicitly to Form.Submit, the onClick works as expected but the Popover will no longer close.

but the Popover will no longer close

Yeah, because e.preventDefault() prevents Radix from closing the popover.

As explained by @joaom00 this is expected behaviour because the Close button is wired to close the popover straight away. When performing any sort of async operation, you'll need to control the state so you can close in your own time.
Have a look at this guide example for Dialog which is the same idea.
https://www.radix-ui.com/primitives/docs/components/dialog#close-after-asynchronous-form-submission


Bug: stringify_attributes() looks unfinished.

https://github.com/codeigniter4/CodeIgniter4/blob/v4.0.4/system/Common.php#L1007
The comment about stringify_attributes() says that the first parameter may be a string, an array and an object type. But I don't see code to handle the object type case, for example a type check and get_object_vars() call.

Or something like this: https://gist.github.com/ericlbarnes/3195974

Line 1034 is the answer you are looking for.

Ah, sorry.


Role Broken, possible external package removed

Error:
TASK [nodesource.node : Install Node.js] ***************************************
fatal: [MYDOMAIN.COM]: FAILED! => {"cache_update_time":<PHONE_NUMBER>, "cache_updated": true, "changed": false, "failed": true, "msg": "'/usr/bin/apt-get -y -o "Dpkg::Options::=--force-confdef" -o "Dpkg::Options::=--force-confold"   install 'nodejs=4.2*'' failed: E: Version '4.2*' for 'nodejs' was not found\n", "stderr": "E: Version '4.2*' for 'nodejs' was not found\n", "stdout": "Reading package lists...\nBuilding dependency tree...\nReading state information...\n", "stdout_lines": ["Reading package lists...", "Building dependency tree...", "Reading state information..."]}

+1 Same issue here.

@vjpr, wanted to make sure you saw the submitted PR. Update defaults/main.yml to have 4.3 as the node version instead of 4.2 and you'll be back up and running
If you're on Mac, ansible roles are stored in /usr/local/etc/ansible/roles

@ryanlelek Thanks! I used your fix already :)

Thanks @ryanlelek, patched this on my machine for now!

@wolfeidau But what if you want to use version 4.2? The nodejs_version seems broken, or should be documented better.

@vjpr I am hoping that @rvagg can shed some light on the removal of 4.2 from the repository.
I am not sure if it has been archived.

The issue is that when the 4.3 release was pushed out to the repo, it unregistered any earlier releases in the 4.x line. So if you do the standard apt-get update and then apt-cache search nodejs now, you'll just see the 4.3 entry.
The earlier versions are there, you'd just have to link directly to the URL IE:
https://deb.nodesource.com/node_4.x/pool/main/n/nodejs/nodejs_4.2.6-1nodesource1~trusty1_amd64.deb

assuming you are using Ubuntu Trusty.

Thanks @chrislea.
So this role should probably be updated to support linking directly to exact versions. I prefer to lock down exact Node.js versions, and upgrade all at once.
And the fix of changing nodejs_version to 4.3 will break when 4.4 is out...so lets keep this issue open @wolfeidau?

Yeah I am guessing I will have to add some sort of escape hatch to work around this.
@chrislea is there a reason it is setup this way?
Cheers

The reason it works this way is that the reprepro command which manages the repo files for all of this and updates them when you add / remove packages doesn't support multiple versions. It will just use whatever the newest one is. Launchpad PPA repos work the same way.
We're looking at changing our tooling so that the repo will show multiple versions, but that's fairly low on the priority list right now internally if I'm being honest.
All that said, one of the major points of the 4.x release line is that being an LTS release, it's never going to break API compatibility when a new version comes out. So you should be totally safe updating to whatever the newest version is at any time without fear of it causing problems. Pinning to a specific version isn't necessary. And frankly, it could be a Bad Thing (tm) if you pinned a version like that. This most recent 4.3 release is a security release that you should definitely want to update to.

Welp, looks like we hit it for 4.4:

E: Version '4.3*' for 'nodejs' was not found

For some reason ansible-galaxy remove didn't work. Workaround was reinstalling with:

sudo -H ansible-galaxy install --force nodesource.node,master

Having the same issue installing default version(4.4) in a vagrant box. I had the same for a previous version of this same role, so I removed and reinstalled the newest version, still getting the same error with a different version number in the stderr output.
TASK [nodesource.node : Install Node.js] ***************************************
fatal: [testRedef]: FAILED! => {"cache_update_time":<PHONE_NUMBER>, "cache_updated": true, "changed": false, "failed": true, "msg": "'/usr/bin/apt-get -y -o \"Dpkg::Options::=--force-confdef\" -o \"Dpkg::Options::=--force-confold\"     install 'nodejs=4.4*'' failed: E: Version '4.4*' for 'nodejs' was not found\n", "stderr": "E: Version '4.4*' for 'nodejs' was not found\n", "stdout": "Reading package lists...\nBuilding dependency tree...\nReading state information...\n", "stdout_lines": ["Reading package lists...", "Building dependency tree...", "Reading state information..."]}

Some additional info. I poked around in the vagrant box after the role failed and I'm seeing that the nodejs package is listed as 0.10.25~dfsg2-2ubuntu1 the default nodejs package provided with ubuntu 14.04. I invoked a apt-get update manually, still the same version shown. There is a file /etc/apt/sources.list.d/deb_nodesource_com_node_4_x.list with the contents:
deb https://deb.nodesource.com/node_4.x trusty main
deb-src https://deb.nodesource.com/node_4.x trusty main

But the repository isn't present on the /etc/apt/sources.list file.

same issue as @tsturzl. Any workarounds ?

Workarounds
set in vars nodejs_version: '4.5'
or patch the main.yml:
on ubuntu this is the file to patch (4.4 -> 4.5):
/etc/ansible/roles/nodesource.node/defaults/main.yml

@chrislea how is this acceptable?
I'm testing playbooks to build a DR environment, and having the node version that currently running in production suddenly become available one day to the next is ridiculous.
I know upgrading 'should' be safe, but that doesn't change that fact that the role breaks every time, and we don't just change production versions on a whim.
If you compare the user experience to something like the AWS AMIs, where they register multiple packages.
eg.
ruby
ruby-20
ruby-21
ruby-22
ruby-23
I'm completely fine with nodejs moving to whatever is latest.  If people want that, all good.  Can't we also have
nodejs-44
nodejs-45
which doesn't get unregistered each time?  Maybe with a warning they are out of date now.

@chrislea the biggest problem for me is that your role simply doesn't work and I'm unable to make it work.
My work around has been to rip the source out of this repo and just removing passing a version number to apt, and then it will just install the latest version of 4.x, which I'm honestly completely fine with. The thing that sucks is that this role is essentially useless at the moment because I have yet to find a workaround that actually works, even if I explicitly provide a version number to the role like @francisdb has mentioned it still fails with the same output.

@tsturzl it is frustrating, and with the release of 4.5 I had to make edits myself and was about to do something similar to what you did.
Current solution is putting this in the groups (or hosts) that use the role. This might make a difference from using role variables depending on your version of Ansible, etc.
Might be worth a shot as a short-term fix while we figure out a long-term.
nodejs_version: "4.5"
( I dont use a wildcard like "x" or "*" because it's already in the role)

Having read over this issue a few times I think we can all agree:

Pinning a specific version using this role is not working reliably for the reasons which @chrislea outlined.

We all really just want to install nodejs

I am therefore proposing to remove the specific version number in favour of towing the party line and just installing what ever is latest in the 4.x or 6.x stream.
This is in accordance with the existing packaging infra.
This is as simple as:
 - name: Install Node.js
   apt:
     pkg:
-      - nodejs={{ nodejs_version }}*
+      - nodejs
     state: installed
     update_cache: yes

Next phase will be to swap to specifying the 4.x or 6.x as a param, with the existing param retained for compatibility.


Setup APK build with PR.

close  #33
Changes

Setup Firebase App Distribution
Build release build and upload to Firebase App Distribution with Github Actions

Codecov Report

Merging #55 (c866e72) into main (c568e95) will not change coverage.
 Consider uploading reports for the commit 56c4129 to get more accurate results

@@            Coverage Diff            @@
##               main      #55   +/-   ##
=========================================
  Coverage     29.38%   29.38%
  Complexity       32       32
=========================================
  Files            45       45
  Lines           565      565
  Branches         81       81
=========================================
  Hits            166      166
  Misses          398      398
  Partials          1        1

Continue to review full report at Codecov.

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


Ability to change postgres log settings

Hi,
We're trying to migrate from zalando operator and we are facing a problem with the logs.
We are using pgBadger to analyze logs generated by postgres.
In zalando the logs are saved in the container (and in a PVC) for one week and rotated:
root@zalando-cluster-0:/home/postgres/pgdata/pgroot/pg_log# ls
postgresql-0.csv  postgresql-1.log  postgresql-2.log  postgresql-3.log  postgresql-4.log  postgresql-5.log  postgresql-6.log  postgresql-7.log
postgresql-1.csv  postgresql-2.csv  postgresql-3.csv  postgresql-4.csv  postgresql-5.csv  postgresql-6.csv  postgresql-7.csv

Using these log files we can run pgBadger without any issue.
The problem is that CNPG throws the logs to stdout without saving them to a file and rotating them.
We tried to change the postgres setting for the logging but in the docs it says all log settings in PostgreSQL are fixed and cannot be changed. So adding log_truncate_on_rotation = 'on' fails.
My question is how can I make it save the logs in the container just like zalando does?

Our design is based on the assumption that we do not store logs in the container, but rather follow the Kubernetes standard so that the application logs in standard output in JSON format directly. See: https://kubernetes.io/docs/concepts/cluster-administration/logging/#how-nodes-handle-container-logs
Specifically, we treat our containers as immutable application containers, rather than a mutable system container in which multiple applications can run inside the container. I understand it is a fundamentally different approach, but it is probably the biggest differentiator between our operator and other operators that work with Postgres.
I suggest you look at the problem by taking a step back, and thinking in Kubernetes terms: this should probably be handled downstream from the operator, using tools like fluentd or similar that reconvert the log from JSON to CSV and have a pod running pgBadger inside. Despite being an early adopter of pgBadger, I must admit I am not anymore up to date with it so I am afraid I cannot provide further help on it.

hi and thanks for your response
while I d your design assumption and that would be probaly great for most users, I don't understand why you cannot be a bit flexible leaving the decision on how to handle logs to the users. the container we'll be still immutable, the logs can be written on the postgres data volume where you want to write data anyways.

I will express my opinion here, so please take it as is. Happy to hear what other people, including maintainers, think and, in any case, I encourage you to propose a pull request and/or participate in one of the next developer meetings.
IMHO this is not a matter of being flexible or not, rather being cloud native as an application and shift to a new way of managing a database. Being a good citizen in Kubernetes for us has been always a priority: this is the way Kubernetes applications expect to manage logs and it is the way we prioritized when developing the logging framework. Consider also that deliberately in this phase we do not support sidecars (for example to run pgBadger) and volumes (for example to store logs). I would for example think of ways to have pgBadger integrate itself with this cloud native setup, rather than the other way around.
Security wise it is also preferable not to store logs in the container.
Sharing PGDATA with user logs would also impact the lifecycle of the database on a self-healing level: think about the case where those logs would fill the space of PGDATA, potentially causing an avalanche effect on the other instances in the cluster which would inevitably lead to human intervention.
Anyway, I don't want to discourage any attempt in this direction. I just don't agree with this direction, but it is my vote.

@viorel-anghel Hi!
If you require to process the logs the proper way will be using a log collector like FluentBit to collect the logs from Pods and the process those logs outside, from there you can store your logs wherever you want without the need of thinking on configure rotation or even delete logs inside the pods! (yes logs use space and sometime you want your PVCs as small as possible).
Using a log collector it's the proper Kubernetes way to collect logs and then do any kind of processing with them, like in your case, use PgBadger, you can export the logs in the format you need with the fields you actually need.
I can see you opened an issue with the PgBadger https://github.com/darold/pgbadger/issues/760 team, if you need a different format for that information you can extract the json and do any task with them after the logs are collected.
Hope this helps you a bit to clarify why the logs use a cloud-native approach for the logs.

@sxd thanks for your input here - you certainly know more than me on this topic! I forgot about fluentbit for this specific case.
@viorel-anghel - FYI @sxd is a fluentbit developer (he developed the PostgreSQL backend support)

A good outcome from this issue could be a documentation page that explains how to implement your use case

Other great solutions supporting log collection from pods are Promtail and vector.dev.

Thanks everyone for the insights.
We are using promtail with loki for log collection.
Our solution is to extract the logs from loki using logcli and send them to pgBadger:

Extract logs from loki

docker run --network=host grafana/logcli:2.7.0-amd64 \
  query '{pod="pg-cluster-1"}' \
  --addr=http://loki-addr:3100/ \
  --limit 1000000 \
  --batch 1000 \
  --since=48h \
  -o raw -q > cnpg-logs.json

Run pgBadger

pgbadger -f jsonlog cnpg-logs.json

pgBadger just added support for cnpg log format: https://github.com/darold/pgbadger/pull/761
I find this solution more expensive than before but at least now we are doing things the cloud native way.

This is great. Thanks a lot for your contribution. Worth blogging about it!  ;)

@cod-r would you like to have containers for pgbadger under cloudnative-pg (similarly to the ones we produce for pgbouncer for example)? If you'd like to maintain them, we are more than happy to host the pipelines here.

Now we have a container with pgbadger, logcli and other stuff inside, so we don't need one with pgbadger only. But if there is demand for it then I can help with this.

@cod-r Could you share solution with pgbadger ale logcli inside container?
I also send all logs to loki this sounds very interesting, much better than manually exporting log and running pgbadger.

it is nothing particularly nice or kubernetes best practices. basically we run a pod based on an ubuntu image in which we installed all the required tools (pgbadger, logcli, nginx, crond) and in this some shell scripts where the main lines are something like
[...]
timeout 1m logcli query "{pod="$pod"}" --addr=$LOKI --limit 1000000 --batch 1000 --since=25h -o raw -q > cnpg-logs.json
pgbadger -f jsonlog -I -j 1 --exclude-appname pg_dump --exclude-user postgres --last-parsed LAST_PARSED -O $dst cnpg-logs.json
[...]


Visual presentation and Resource Detection for eks

Describe the bug
This is more of a question of functionality rather then a potential bug.
My issue is similar to a previously reported bug.
Is it possible to expose and present infra metadata in x-ray?
At the moment the resources appear in x-ray but states my pods are coming from the origin: AWS::EC2::Instance.
I was hoping this would be a bit more specific and say that rather being an EC2 instance (while strictly true) it belongs to the eks cluster (eksstg).

I've configure the following for this app:
            - name: AWS_REGION
              value: eu-west-1
            - name: LISTEN_ADDRESS
              value: <IP_ADDRESS>:8080
            - name: OTEL_EXPORTER_OTLP_ENDPOINT
              value: http://my-collector-xray-collector.otel:4317
            - name: OTEL_RESOURCE_ATTRIBUTES
              value: service.namespace=content,service.name=archive-web,k8s.cluster.name=eksstg
            - name: OTEL_SERVICE_NAME
              value: archive-web
            - name: OTEL_TRACES_EXPORTER
              value: otlp
            - name: OTEL_METRICS_EXPORTER
              value: none

The collector config
Version: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: my-collector-xray
spec:
  mode: deployment
  resources:
    requests:
      cpu: "1"
    limits:
      cpu: "1"
  serviceAccount: adot-collector
  config: |
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: <IP_ADDRESS>:4317
          http:
            endpoint: <IP_ADDRESS>:4318
    processors:
      batch/traces:
        timeout: 1s
        send_batch_size: 50
      resourcedetection/eks:
        detectors: [env, eks]
        timeout: 2s
        override: false

#taken from here
# https://opentelemetry.io/docs/collector/configuration/#processors

      resource:
        attributes:
          - key: cloud.zone
            value: "zone-1"
            action: upsert
          - key: k8s.cluster.name
            from_attribute: k8s-cluster
            action: insert
          - key: redundant-attribute
            action: delete

    exporters:
      awsxray:
        region: eu-west-1

      logging:
        loglevel: debug
    service:
      pipelines:
        traces:
          receivers: [otlp]
          processors: [batch/traces]
          exporters: [awsxray,logging]

      telemetry:
        logs:
          level: debug

my setup

eks v1.22
aws otel agent (Release v1.21.1)
latest Adot operator installed via Deployment mode (v0.66.0-eksbuild.1)

The suggestions from the bug above goes on to say I should enable Resource Detection.
Firstly could someone confirm if the correct implementation of the Detector should be (as per the original bug suggestion:
processors:
  resourcedetection/env:
    detectors: [env]
    timeout: 2s
    override: false

or
https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/resourcedetectionprocessor/README.md#amazon-eks
processors:
  resourcedetection/eks:
    detectors: [env, eks]
    timeout: 2s
    override: false

Regards,
Ben

Your resourcedetection/env processor config looks good for detecting EKS platform, but you missed it in your pipelines/traces configuration section.
pipelines:
        traces:
          receivers: [otlp]
          processors: [resourcedetection/env, batch/traces]
          exporters: [awsxray,logging]

Thanks for spotting that.
I've added the below but it's not change anything visually - any other suggestions are very welcome.
processors: [resourcedetection/eks, batch/traces]


Not letting me replace a href with a hashtag to make a dead link...

Challenge Make Dead Links using the Hash Symbol has an issue.
User Agent is: Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36.
Please describe how to reproduce this issue, and include links to screenshots if possible.

Just enter # nothing else it means default , it never = to anything

if u want to link to ur own screenshots , upload them to generate link starting http://.............
and simply replace pictures with your link e.g

Hi @johnnytuxedo! Thanks for reporting this issue! Your problem has already been fixed in https://github.com/FreeCodeCamp/FreeCodeCamp/issues/11297. It is not on the site you're using just yet, but it will be in the future.
If you need coding help, please use the 'Help' button on the challenge. The issue tracker is not for coding help.
Happy coding!


Docs(Advanced > NextSteps.md): typos/wording tweaks

Hi there! Made a few typo/grammar fixes, and a couple of small wording changes.   Thanks for the great docs :)

Thanks!


Add Herb Farming Calculator plugin

This plugin calculates potential profit and XP from farming herbs. It's basically a more powerful and easier-to-use version of the Wiki's calculator. The idea is that you configure the plugin once based on what patches and items you use, then any time you open the panel, it'll tell you what herb you should be farming based on current prices to make the most profit.
Here's an example of the output:

You should not set enabledByDefault in your PluginDescriptor; it confuses users.
You must remove your navbutton in shutDown
otherwise LGTM

You should not set enabledByDefault in your PluginDescriptor; it confuses users. You must remove your navbutton in shutDown otherwise LGTM

Thanks for the review, just fixed both of those things so it should be good to go know.


Update CHANGELOG for 3.0.1 release.

3.0.1 - 2017-07-17

Fixed issue #592 where the --manifest-out option of bin/polymer-bundler did not correctly include the basis document of shell files in inlined content list.

Small bug fix.  No docs-impacting changes.


Improve runtime dispatch sanity

try to fix the runtime dispatch errors with https://github.com/aviatesk/JETTest.jl.

closed by f2bfa48a9e293e68af93a29be92dde07ffd15bf0


Removed annoying formatting rules from recommended ruleset

PR checklist

[x] Addresses an existing issue: fixes #1520, fixes #3248, fixes #4305, fixes #4869.
[x] New feature, bugfix, or enhancement

~[ ] Includes tests~

~[ ] Documentation update~

Overview of change:
Removes a bunch of rules from recommended.ts around formatting and whitespace. Also adds allow-leading-underscore to variable-name.
CHANGELOG.md entry:
[rule-change] Removed formatting and whitespace rules from recommended ruleset

When will this be released? :)

😢 @JoshuaKGoldberg why these changes? it removes a lot of very appreciable rules in the so-called "recommended" rule set

Great .. i was wondering why code suddenly did not have enforced rules. Trailingsemicolon and commans are for better git changelogs. We relied on the recommended to better document what we wanted to tweak... this was probably a wrong decision ... No wi need to clean up a lot of mess cause devs of course upgraded tslint package and got less strict new defaults.

For pure styling I would recommend prettier. This will also autofix your code :)

For good reason were not. Those checks are not for styling but good reason as clean git history. I would approve some of the removals which are highly opinionated. But commans and curly braces as well as semicolons have more meaning and often clutter diffs.

This change to the recommended rule set had been planned for a very long time. TSLint is deprecated and we won't be making any more significant changes to its API.


Add the ability to ban certain users.

Seriously, do something about this. The very least you should respect forum bans in shoutbox also -> remove the ability to post in the shoutbox if the user has forum bans. This is a really nasty problem.
100% no tools to combat spammers, unwanted users etc.
I think you should put  this on the top of your list and put the 5 minutes of work into it that it would take to implement, bugtest and release this feature.
Thanks!

Any progress or is this abandoned?

Not abandoned, just that full time internship means less time for things like this.


Add PHP7 support

Coverage remained the same at 100.0% when pulling 9ddf843ae66beb122cddc79d5398d75f3472ae67 on add-php7-support into 224199137d571608b665e4fe9f4a9469f260adb0 on master.


integer values to large for JSON.stringify / Javascript do get messed up.

Always be sure to save as string in that case.

Moved to [Enhancement] create contributing guidelines

Moved to [Enhancement] create contributing guidelines


support for tent.io

Would be great to also see tent.io support in this app.

Currently it doesn't look like the time came to support Tent.io :-)
It's still mostly on a paper, no users community yet...
?!


quote decode error

Thanks for reporting this @xoyteam, this should be fixed in https://github.com/smallwat3r/shhh/pull/279

Thanks works fine!


Volume is read-only with MacOS Finder as client

The issues appears to be that MacOS's finder requires the DAV server to be level 2 with lock support in order to allow write access.  Since webdavd reports DAV 1, it will only allow read-only access.
Write access works fine with another client, e.g. cadaver.

This is fixed by PR #21


Add missing scope tags to connection options

🔧 Changes
Through https://github.com/auth0/go-auth0/pull/263/files we introduced the ExtGroups and ExtProfile properties on the ConnectionOptionsPingFederate and ConnectionOptionsSAML, however the scope tag was missed. This PR addresses that.
To note also that unfortunately now we have inconsistent ways of describing the same attribute accepted by the API:
ext_groups

ConnectionOptionsPingFederate.ExtGroups
ConnectionOptionsSAML.ExtGroups
ConnectionOptionsAzureAD.Groups
ConnectionOptionsGoogleApps.Groups

ext_profile

ConnectionOptionsPingFederate.ExtProfile
ConnectionOptionsSAML.ExtProfile
ConnectionOptionsGoogleApps.ExtendedProfile
ConnectionOptionsAzureAD.ExtendedProfile

📚 References

🔬 Testing

📝 Checklist

[x] All new/changed/fixed functionality is covered by tests (or N/A)
[x] I have added documentation for all new/changed functionality (or N/A)

Codecov Report
Patch and project coverage have no change.

Comparison is base (ac7326c) 94.78% compared to head (91c61b9) 94.78%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #269   +/-   ##
=======================================
  Coverage   94.78%   94.78%
=======================================
  Files          46       46
  Lines        8733     8733
=======================================
  Hits         8278     8278
  Misses        353      353
  Partials      102      102

Files Changed
Coverage Δ

management/connection.go
75.00% <ø> (ø)

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


OneNote in Kiosk Mode

We're trying to utilize the accessibility tools in OneNote specifically the dictate tool to provide needed accommodations to our students during testing. We're required to lock the computer down to a single app (onenote) and only the draw tab shows.
Is there any way that the all the features of the OneNote app can be enabled in Kiosk Mode?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: bd2d1007-2cbb-94a6-18aa-a0b879262ab1
Version Independent ID: 625d9906-0cb0-23eb-3a56-a84ad774d291
Content: Guidelines for choosing an app for assigned access (Windows 10)
Content Source: windows/configuration/guidelines-for-assigned-access-app.md
Product: w10
GitHub Login: @jdeckerMS
Microsoft Alias: jdecker

@rickgode Are you using the UWP (Microsoft Store) OneNote app or the desktop (Win32) app? Also, what method are you using to configure kiosk mode?

@officedocsbot assign @mypil

@rickgode - Can you please respond to the query of jdeckerms?

@rickgode - We appreciate any feedback that improves the content in the Microsoft docs but we haven't had any response from you so we are going to close this issue.
Please feel free to open a new issue if there is a specific area of the docs that we can improve or make better. Thank you.

@officedocsbot close


[stable/mongodb] Service does not resolve to an endpoint.

Describe the bug
Unable to access MongoDB cluster. IP address resolves but cannot connect to MongoDB. After debugging a bit, I understood that the issue is most likely due to missing endpoints in the service specification.
Version of Helm and Kubernetes:
Helm Version:
╰─[:)] % helm version
Client: &version.Version{SemVer:"v2.14.1", GitCommit:"5270352a09c7e8b6e8c9593002a73535276507c0", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.14.1", GitCommit:"5270352a09c7e8b6e8c9593002a73535276507c0", GitTreeState:"clean"}

Kubernetes Version:
╰─[:)] % kubectl version
Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.3", GitCommit:"5e53fd6bc17c0dec8434817e69b04a25d8ae0ff0", GitTreeState:"clean", BuildDate:"2019-06-06T01:44:30Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.8", GitCommit:"a89f8c11a5f4f132503edbc4918c98518fd504e3", GitTreeState:"clean", BuildDate:"2019-04-23T04:41:47Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}

Which chart:
stable/mongodb
What happened:
╰─[:)] % kubectl -n data describe svc
Name:              mongo-test-mongodb
Namespace:         data
Labels:            app=mongodb
                   chart=mongodb-6.1.0
                   heritage=Tiller
                   release=mongo-test
Annotations:       <none>
Selector:          app=mongodb,component=primary,release=mongo-test
Type:              ClusterIP
IP:                <IP_ADDRESS>
Port:              mongodb  27017/TCP
TargetPort:        mongodb/TCP
Endpoints:
Port:              metrics  9216/TCP
TargetPort:        metrics/TCP
Endpoints:
Session Affinity:  None
Events:            <none>

Name:              mongo-test-mongodb-headless
Namespace:         data
Labels:            app=mongodb
                   chart=mongodb-6.1.0
                   heritage=Tiller
                   release=mongo-test
Annotations:       <none>
Selector:          app=mongodb,release=mongo-test
Type:              ClusterIP
IP:                None
Port:              mongodb  27017/TCP
TargetPort:        27017/TCP
Endpoints:
Session Affinity:  None
Events:            <none>

What you expected to happen:
To be able to communicate with MongoDB instances.
How to reproduce it (as minimally and precisely as possible):
Install the latest MongoDB chart from Helm and try to connect it via. a client from inside Kubernetes cluster.
Anything else we need to know:

Hi @abheyogy, we could get it to working with the instructions from the helm install . command from the stable/mongodb directory in the chart (same as helm install stable/mongodb):
To get the root password run:

    export MONGODB_ROOT_PASSWORD=$(kubectl get secret --namespace default zooming-ibis-mongodb -o jsonpath="{.data.mongodb-root-password}" | base64 --decode)

To connect to your database run the following command:

    kubectl run --namespace default zooming-ibis-mongodb-client --rm --tty -i --restart='Never' --image bitnami/mongodb --command -- mongo admin --host zooming-ibis-mongodb --authenticationDatabase admin -u root -p $MONGODB_ROOT_PASSWORD

To connect to your database from outside the cluster execute the following commands:

    kubectl port-forward --namespace default svc/zooming-ibis-mongodb 27017:27017 &
    mongo --host <IP_ADDRESS> --authenticationDatabase admin -p $MONGODB_ROOT_PASSWORD

When we execute the command below we get to the MongoDB prompt:
$ kubectl run --namespace default zooming-ibis-mongodb-client --rm --tty -i --restart='Never' --image bitnami/mongodb --command -- mongo admin --host zooming-ibis-mongodb --authenticationDatabase admin -u root -p $MONGODB_ROOT_PASSWORD
If you don't see a command prompt, try pressing enter.

> list dbs;

Doing it externally also worked:
$ kubectl port-forward --namespace default svc/zooming-ibis-mongodb 27017:27017 &
$ mongo --host <IP_ADDRESS> --authenticationDatabase admin -p $MONGODB_ROOT_PASSWORD
MongoDB shell version v4.0.3
connecting to: mongodb://<IP_ADDRESS>:27017/
Implicit session: session { "id" : UUID("f5cbc79e-d403-45a9-b03f-38229d046f41") }
MongoDB server version: 4.0.11
> ^C
bye

@marcosbc I redeployed mongo using the helm command, and on trying to connect to the DB, it fails.
However, I am able to connect to mongodb when I do a port-forwarding.
❯ kubectl run --namespace mongo mongo-helm-mongodb-client --rm --tty -i --restart='Never' --image bitnami/mongodb --command -- mongo admin --host mongo-helm-mongodb --authenticationDatabase admin -u root -p $MONGODB_ROOT_PASSWORD

If you don't see a command prompt, try pressing enter.

2019-08-12T03:51:03.416+0000 E QUERY    [js] Error: couldn't connect to server mongo-helm-mongodb:27017, connection attempt failed: SocketException: Error connecting to mongo-helm-mongodb:27017 (<IP_ADDRESS>:27017) :: caused by :: Connection timed out :
connect@src/mongo/shell/mongo.js:344:17
@(connect):2:6
exception: connect failed
pod "mongo-helm-mongodb-client" deleted
pod mongo/mongo-helm-mongodb-client terminated (Error)

Looking at the service description, I see that the endpoints is empty which should have had the pod's IP:PORT.
Name:              mongo-helm-mongodb
Namespace:         mongo
Labels:            app=mongodb
                   chart=mongodb-7.0.1
                   heritage=Tiller
                   release=mongo-helm
Annotations:       <none>
Selector:          app=mongodb,component=primary,release=mongo-helm
Type:              ClusterIP
IP:                <IP_ADDRESS>
Port:              mongodb  27017/TCP
TargetPort:        mongodb/TCP
Endpoints:
Port:              metrics  9216/TCP
TargetPort:        metrics/TCP
Endpoints:
Session Affinity:  None
Events:            <none>

Name:              mongo-helm-mongodb-headless
Namespace:         mongo
Labels:            app=mongodb
                   chart=mongodb-7.0.1
                   heritage=Tiller
                   release=mongo-helm
Annotations:       <none>
Selector:          app=mongodb,release=mongo-helm
Type:              ClusterIP
IP:                None
Port:              mongodb  27017/TCP
TargetPort:        27017/TCP
Endpoints:         <IP_ADDRESS>:27017
Session Affinity:  None
Events:            <none>

Could you please guide me on what I may be missing here? Here is my values.yaml
## Global Docker image parameters
## Please, note that this will override the image parameters, including dependencies, configured to use the global value
## Current available global Docker image parameters: imageRegistry and imagePullSecrets
##
# global:
#   imageRegistry: myRegistryName
#   imagePullSecrets:
#     - myRegistryKeySecretName

image:
  ## Bitnami MongoDB registry
  ##
  registry: docker.io
  ## Bitnami MongoDB image name
  ##
  repository: bitnami/mongodb
  ## Bitnami MongoDB image tag
  ## ref: https://hub.docker.com/r/bitnami/mongodb/tags/
  ##
  tag: 4.0.11-debian-9-r0
  ## Specify a imagePullPolicy
  ## ref: http://kubernetes.io/docs/user-guide/images/#pre-pulling-images
  ##
  pullPolicy: IfNotPresent
  ## Optionally specify an array of imagePullSecrets.
  ## Secrets must be manually created in the namespace.
  ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
  ##
  # pullSecrets:
  #   - myRegistryKeySecretName

  ## Set to true if you would like to see extra information on logs
  ## It turns on Bitnami debugging in minideb-extras-base
  ## ref:  https://github.com/bitnami/minideb-extras-base
  debug: false

## String to partially override mongodb.fullname template (will maintain the release name)
##
# nameOverride:

## String to fully override mongodb.fullname template
##
# fullnameOverride:

## Init containers parameters:
## volumePermissions: Change the owner and group of the persistent volume mountpoint to runAsUser:fsGroup values from the securityContext section.
##
volumePermissions:
  enabled: false
  image:
    registry: docker.io
    repository: bitnami/minideb
    tag: latest
    pullPolicy: Always
    ## Optionally specify an array of imagePullSecrets.
    ## Secrets must be manually created in the namespace.
    ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
    ##
    # pullSecrets:
    #   - myRegistryKeySecretName
  resources: {}

## Enable authentication
## ref: https://docs.mongodb.com/manual/tutorial/enable-authentication/
#
usePassword: true
# existingSecret: name-of-existing-secret

## MongoDB admin password
## ref: https://github.com/bitnami/bitnami-docker-mongodb/blob/master/README.md#setting-the-root-password-on-first-run
##
mongodbRootPassword: XXXXXXXX

## MongoDB custom user and database
## ref: https://github.com/bitnami/bitnami-docker-mongodb/blob/master/README.md#creating-a-user-and-database-on-first-run
##
mongodbUsername: XXXXXXXX
mongodbPassword: XXXXXXXX
mongodbDatabase: XXXXXXXX

## Whether enable/disable IPv6 on MongoDB
## ref: https://github.com/bitnami/bitnami-docker-mongodb/blob/master/README.md#enabling/disabling-ipv6
##
mongodbEnableIPv6: false

## Whether enable/disable DirectoryPerDB on MongoDB
## ref: https://github.com/bitnami/bitnami-docker-mongodb/blob/master/README.md#enabling/disabling-directoryperdb
##
mongodbDirectoryPerDB: false

## MongoDB System Log configuration
## ref: https://github.com/bitnami/bitnami-docker-mongodb#configuring-system-log-verbosity-level
##
mongodbSystemLogVerbosity: 0
mongodbDisableSystemLog: false

## MongoDB additional command line flags
##
## Can be used to specify command line flags, for example:
##
## mongodbExtraFlags:
##  - "--wiredTigerCacheSizeGB=2"
mongodbExtraFlags: []

## Pod Security Context
## ref: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
##
securityContext:
  enabled: true
  fsGroup: 1001
  runAsUser: 1001

## Kubernetes Cluster Domain
clusterDomain: cluster.local

## Kubernetes service type
service:
  annotations: {}
  type: ClusterIP
  # clusterIP: None
  port: 27017

  ## Specify the nodePort value for the LoadBalancer and NodePort service types.
  ## ref: https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport
  ##
  # nodePort:

  ## Specify the externalIP value ClusterIP service type.
  ## ref: https://kubernetes.io/docs/concepts/services-networking/service/#external-ips
  # externalIPs: []

  ## Specify the loadBalancerIP value for LoadBalancer service types.
  ## ref: https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer
  ##
  # loadBalancerIP:

  ## Specify the loadBalancerSourceRanges value for LoadBalancer service types.
  ## ref: https://kubernetes.io/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/#restrict-access-for-loadbalancer-service
  ##
  # loadBalancerSourceRanges: []

## Setting up replication
## ref: https://github.com/bitnami/bitnami-docker-mongodb#setting-up-a-replication
#
replicaSet:
  ## Whether to create a MongoDB replica set for high availability or not
  enabled: true
  useHostnames: true

  ## Name of the replica set
  ##
  name: rs0

  ## Key used for replica set authentication
  ##
  # key: key

  ## Number of replicas per each node type
  ##
  replicas:
    secondary: 1
    arbiter: 1

  ## Pod Disruption Budget
  ## ref: https://kubernetes.io/docs/concepts/workloads/pods/disruptions/
  pdb:
    enabled: true
    minAvailable:
      secondary: 1
      arbiter: 1
    # maxUnavailable:
      # secondary: 1
      # arbiter: 1

# Annotations to be added to MongoDB pods
podAnnotations: {}

# Additional pod labels to apply
podLabels: {}

## Use an alternate scheduler, e.g. "stork".
## ref: https://kubernetes.io/docs/tasks/administer-cluster/configure-multiple-schedulers/
##
# schedulerName:

## Configure resource requests and limits
## ref: http://kubernetes.io/docs/user-guide/compute-resources/
##
resources: {}
# limits:
#   cpu: 500m
#   memory: 512Mi
# requests:
#   cpu: 100m
#   memory: 256Mi

## Pod priority
## https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/
# priorityClassName: ""

## Node selector
## ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#nodeselector
nodeSelector: {}

## Affinity
## ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity
affinity: {}

## Tolerations
## ref: https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/
tolerations: []

## updateStrategy for MongoDB Primary, Secondary and Arbitrer statefulsets
## ref: https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#update-strategies
updateStrategy:
  type: RollingUpdate

## Enable persistence using Persistent Volume Claims
## ref: http://kubernetes.io/docs/user-guide/persistent-volumes/
##
persistence:
  enabled: true
  ## A manually managed Persistent Volume and Claim
  ## Requires persistence.enabled: true
  ## If defined, PVC must be created manually before volume will be bound
  ##
  # existingClaim:

  ## The path the volume will be mounted at, useful when using different
  ## MongoDB images.
  ##
  mountPath: /bitnami/mongodb

  ## The subdirectory of the volume to mount to, useful in dev environments
  ## and one PV for multiple services.
  ##
  subPath: ""

  ## mongodb data Persistent Volume Storage Class
  ## If defined, storageClassName: <storageClass>
  ## If set to "-", storageClassName: "", which disables dynamic provisioning
  ## If undefined (the default) or set to null, no storageClassName spec is
  ##   set, choosing the default provisioner.  (gp2 on AWS, standard on
  ##   GKE, AWS & OpenStack)
  ##
  storageClass: default #rook-ceph-block
  accessModes:
    - ReadWriteOnce
  size: 8Gi
  annotations: {}

## Configure the ingress resource that allows you to access the
## MongoDB installation. Set up the URL
## ref: http://kubernetes.io/docs/user-guide/ingress/
##
ingress:
  ## Set to true to enable ingress record generation
  enabled: false

  ## Set this to true in order to add the corresponding annotations for cert-manager
  certManager: false

  ## Ingress annotations done as key:value pairs
  ## For a full list of possible ingress annotations, please see
  ## ref: https://github.com/kubernetes/ingress-nginx/blob/master/docs/annotations.md
  ##
  ## If tls is set to true, annotation ingress.kubernetes.io/secure-backends: "true" will automatically be set
  ## If certManager is set to true, annotation kubernetes.io/tls-acme: "true" will automatically be set
  annotations:
  #  kubernetes.io/ingress.class: nginx

  ## The list of hostnames to be covered with this ingress record.
  ## Most likely this will be just one host, but in the event more hosts are needed, this is an array
  hosts:
  - name: mongodb.local
    path: /

  ## The tls configuration for the ingress
  ## see: https://kubernetes.io/docs/concepts/services-networking/ingress/#tls
  tls:
  - hosts:
      - mongodb.local
    secretName: mongodb.local-tls

  secrets:
  ## If you're providing your own certificates, please use this to add the certificates as secrets
  ## key and certificate should start with -----BEGIN CERTIFICATE----- or
  ## -----BEGIN RSA PRIVATE KEY-----
  ##
  ## name should line up with a tlsSecret set further up
  ## If you're using cert-manager, this is unneeded, as it will create the secret for you if it is not set
  ##
  ## It is also possible to create and manage the certificates outside of this helm chart
  ## Please see README.md for more information
  # - name: airflow.local-tls
  #   key:
  #   certificate:

## Configure the options for init containers to be run before the main app containers
## are started. All init containers are run sequentially and must exit without errors
## for the next one to be started.
## ref: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
# extraInitContainers: |
#   - name: do-something
#     image: busybox
#     command: ['do', 'something']

## Configure extra options for liveness and readiness probes
## ref: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#configure-probes)
livenessProbe:
  enabled: true
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 6
  successThreshold: 1
readinessProbe:
  enabled: true
  initialDelaySeconds: 5
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 6
  successThreshold: 1

# Define custom config map with init scripts
initConfigMap: {}
#  name: "init-config-map"

# Entries for the MongoDB config file
configmap:
#  # Where and how to store data.
#  storage:
#    dbPath: /opt/bitnami/mongodb/data/db
#    journal:
#      enabled: true
#    #engine:
#    #wiredTiger:
#  # where to write logging data.
#  systemLog:
#    destination: file
#    logAppend: true
#    path: /opt/bitnami/mongodb/logs/mongodb.log
#  # network interfaces
#  net:
#    port: 27017
#    bindIp: <IP_ADDRESS>
#    unixDomainSocket:
#      enabled: true
#      pathPrefix: /opt/bitnami/mongodb/tmp
#  # replica set options
#  replication:
#    replSetName: replicaset
#  # process management options
#  processManagement:
#     fork: false
#     pidFilePath: /opt/bitnami/mongodb/tmp/mongodb.pid
#  # set parameter options
#  setParameter:
#     enableLocalhostAuthBypass: true
#  # security options
#  security:
#    authorization: enabled
#    keyFile: /opt/bitnami/mongodb/conf/keyfile

## Prometheus Exporter / Metrics
##
metrics:
  enabled: true

  image:
    registry: docker.io
    repository: forekshub/percona-mongodb-exporter
    tag: latest
    pullPolicy: Always
    ## Optionally specify an array of imagePullSecrets.
    ## Secrets must be manually created in the namespace.
    ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
    ##
    # pullSecrets:
    #   - myRegistryKeySecretName

  ## String with extra arguments to the metrics exporter
  ## ref: https://github.com/dcu/mongodb_exporter/blob/master/mongodb_exporter.go
  extraArgs: ""

  ## Metrics exporter resource requests and limits
  ## ref: http://kubernetes.io/docs/user-guide/compute-resources/
  ##
  # resources: {}

  ## Metrics exporter liveness and readiness probes
  ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#configure-probes)
  livenessProbe:
    enabled: true
    initialDelaySeconds: 15
    periodSeconds: 5
    timeoutSeconds: 5
    failureThreshold: 3
    successThreshold: 1
  readinessProbe:
    enabled: true
    initialDelaySeconds: 5
    periodSeconds: 5
    timeoutSeconds: 1
    failureThreshold: 3
    successThreshold: 1

  ## Metrics exporter pod Annotation
  podAnnotations:
    prometheus.io/scrape: "true"
    prometheus.io/port: "9216"

  ## Prometheus Service Monitor
  ## ref: https://github.com/coreos/prometheus-operator
  ##      https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md
  serviceMonitor:
    ## If the operator is installed in your cluster, set to true to create a Service Monitor Entry
    enabled: false

    ## Specify a namespace if needed
    # namespace: monitoring

    ## Used to pass Labels that are used by the Prometheus installed in your cluster to select Service Monitors to work with
    ## ref: https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#prometheusspec
    additionalLabels: {}

    ## Specify Metric Relabellings to add to the scrape endpoint
    ## ref: https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#endpoint
    # relabellings:

    alerting:
      ## Define individual alerting rules as required
      ## ref: https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#rulegroup
      ##      https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/
      rules: {}

      ## Used to pass Labels that are used by the Prometheus installed in your cluster to select Prometheus Rules to work with
      ## ref: https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#prometheusspec
      additionalLabels: {}

Hi @abheyogy, I'm so sorry for the delay on getting back to you. This issue was not properly tracked by our internal GitHub Issues tracker, so we weren't notified about your reply. We've launched an internal investigation to prevent this from happening in the future.
Do you keep finding this issue? We keep being unable to reproduce this, and have tried both in Minikube and in a GKE cluster.
However, you mentioned the service not showing an endpoint which does not happen in our case:
$ kubectl describe svc mymongodb
Name:              mymongodb
Namespace:         default
Labels:            app=mongodb
                   chart=mongodb-7.2.7
                   heritage=Tiller
                   release=mymongodb
Annotations:       <none>
Selector:          app=mongodb,component=primary,release=mymongodb
Type:              ClusterIP
IP:                <IP_ADDRESS>
Port:              mongodb  27017/TCP
TargetPort:        mongodb/TCP
Endpoints:         <IP_ADDRESS>:27017
Port:              metrics  9216/TCP
TargetPort:        metrics/TCP
Endpoints:         <IP_ADDRESS>:9216
Session Affinity:  None
Events:            <none>

Name:              mymongodb-headless
Namespace:         default
Labels:            app=mongodb
                   chart=mongodb-7.2.7
                   heritage=Tiller
                   release=mymongodb
Annotations:       <none>
Selector:          app=mongodb,release=mymongodb
Type:              ClusterIP
IP:                None
Port:              mongodb  27017/TCP
TargetPort:        27017/TCP
Endpoints:         <IP_ADDRESS>:27017,<IP_ADDRESS>:27017,<IP_ADDRESS>:27017
Session Affinity:  None
Events:            <none>```

You can see the headless has one endpoint per node (primary, arbiter and secondary). In your case this does not happen, which we believe could be happening because the pods are not running. It would be great if you could check if pods are running and ready:

    kubectl get pods


Intune reporting error when using runMDATPQuickScan.sh

Intune reports that the script ran with errors but it does work. I added "exit 0" to the end of the script and it seems to work. I would recommend updating the script. Thanks for the great work!

Submitted Pull request

Pull merged. Issue resolved.


The squared social Buttons and Rounded social buttons should be separated for clear UI

Is your feature request related to a problem? Please describe.
Describe the solution you'd like
Additional notes

I want to work on this can I?????

I thought of same but isn't it better if they are side by side and user can see differences?

Might be but in the page every button is separated by its square and rounded . So it is looking odd ............. is not it????

Everyone has their own views. I think admin should decide what to do, yeah but we can do give suggestions though.

Yup

@Neeraj3508 and @dsnehasish74 I've commented on this here. @dsnehasish74 let me know if you can work on it as I described it there. If not, maybe @Neeraj3508 would like to work on it. Let me know who can work on this.

Yes, i would love to contribute.

Ok @Neeraj3508 I'll assign you. Please let me know if you need any assistance.

@shahednasser  any deadlines?

No there's no deadline @Neeraj3508 since this is just an enhancement, not a bug.

Please can u again repeat the task exactly

@Neeraj3508 we need to make social buttons consistent with the rest of the website and button types. Currently if you add rounded-btn to any button type it will make the button rounded. Instead of having two different classes for each social type (For example facebook and facebook-rounded) we should just add rouneded-btn to the social button and it will make it rounded. This will make the usage of sButtons consistent and easier to get the hang of it.
Once this is done, we can then display social buttons similar to other button styles (not rounded buttons first, rounded buttons later).

Yes but that will create one issue that is the border radius for rounded btn class ia 25px and here as the field is long in social buttons case the curves won't be that smooth

Then you can add a rule specific for .social-btn.rounded-btn that overrides the original border-radius rule

Ok

Issue has been resolved by code refactoring to make website more consistent. Thank you @Neeraj3508 and @dsnehasish74


[aiflow] the objective of “workflow” table?

There are no actual things to do with the workflow table, what's the objective of this? You guys will remove or re-design this table shortly?

@ryantd , the worflow table is used to persist the metadata of workflow. Users could get the metadata of the workflow on another worflow.

@ryantd , the worflow table is used to persist the metadata of workflow. Users could get the metadata of the workflow on another worflow.

@SteNicholas appreciate your answer, and yes, understood what your thinking. However in your repo, I don't find any data that will save into the "workflow" table, all of the "metadata of workflow" have been already saved into the "workflow_execution" table.

@SteNicholas appreciate your answer, and yes, understood what your thinking. However in your repo, I don't find any data that will save into the "workflow" table, all of the "metadata of workflow" have been already saved into the "workflow_execution" table.


Swagger directives not detected in imported package?

We have a package that implements an endpoint, which we then add to our router in our main code.
We're unable to get swagger-autogen to recognize this endpoint properly; we'd be happy either if we could document it or tell swagger-autogen to ignore it.
In our package, I have this exported:
const buildInfo = (req: Request, res: Response) => {
  // #swagger.ignore = true

  res.status(200).json(getBuildInfo());
};

We add this package to our main service with yarn add, and then we call it like so while setting up our Express routes:
import { buildInfo } from 'build-info';

const router = express.Router();
router.get('/info', buildInfo);

The route works just fine when we access it through Express.
However, swagger-autogen is including the route in our OpenAPI JSON, but it's invalid (so our OpenAPI validator barfs on it):
    "/api/v1/service/info": {
      "get": {
        "description": "",
        "parameters": [],
        "responses": {}
      }
    }

(I believe it's that responses must not be empty)
I've tried providing full swagger-autogen comments in the package, but that's not working either.
As I said, we'd be happy to either have this route omitted from the OpenAPI generated, or be able to supply full spec on it so that the resulting OpenAPI spec is valid.

Okay, I just found a workaround.  In my package I've added:
const addBuildInfo = (router: Router, path: string) => {
  router.get(path, buildInfo);
}

and exported it, and then in the consuming app:
import { addBuildInfo } from 'build-info';

const router = express.Router();
...
addBuildInfo(router, '/info');

This at least keeps swagger-autogen from finding the route, which I think is okay for us for now.

Hi @denis-haskin-elemental. Sorry for the delay and thank you for opening the issue.
Probably the swagger-autogen are not reaching your function buildInfo and so, not seeing the ìgnore`, because it searches only for local files.
An other workaround it's put the #swagger.ignore = true outside of the callback, such as:
import { buildInfo } from 'build-info';

const router = express.Router();
router.get('/info', buildInfo /* #swagger.ignore = true */);

But I'll try to handle that case. Any news I'll post it here. Thanks!


Stuck in Downloading VS Code Server for Remote SSH Connection

VS Code Version: 1.91.1
Commit: f1e16e1e6214d7c44d078b1f0607b2388f29d729
Date: 2024-07-09T22:08:12.169Z
Electron: 29.4.0
ElectronBuildId: 9728852
Chromium: 122.0.6261.156
Node.js: 20.9.0
V8: 12.2.281.27-electron.0
OS: Linux x64 6.5.0-45-generic

Remote - SSH Extension Version: v0.112.0

The issue #192564 with the Remote - SSH extension unfortunately is still present. Once I want to connect to a Linux SSH server (in my case Debian 12 Bookworm) I get stuck with the message "Setting up SSH Host: [Hostname] Downloading VS Code Server":

I then connected to the server and looked what happens there actually. It is this line:
wget --tries=1 --connect-timeout=7 --dns-timeout=7 -nv -O vscode-server.tar.gz https://update.code.visualstudio.com/commit:f1e16e1e6214d7c44d078b1f0607b2388f29d729/server-linux-legacy-x64/stable

When I tried to download it manually, it also gets stuck. It stays at Connecting ... connected. forever:
wget https://update.code.visualstudio.com/commit:f1e16e1e6214d7c44d078b1f0607b2388f29d729/server-linux-legacy-x64/stable
--2024-07-30 09:44:44--  https://update.code.visualstudio.com/commit:f1e16e1e6214d7c44d078b1f0607b2388f29d729/server-linux-legacy-x64/stable
Resolving update.code.visualstudio.com (update.code.visualstudio.com)... <IP_ADDRESS>, 2620:1ec:bdf::45
Connecting to update.code.visualstudio.com (update.code.visualstudio.com)|<IP_ADDRESS>|:443... connected.

On my local Linux server at home though it works:
wget https://update.code.visualstudio.com/commit:f1e16e1e6214d7c44d078b1f0607b2388f29d729/server-linux-legacy-x64/stable
--2024-07-30 11:46:17--  https://update.code.visualstudio.com/commit:f1e16e1e6214d7c44d078b1f0607b2388f29d729/server-linux-legacy-x64/stable
Resolving update.code.visualstudio.com (update.code.visualstudio.com)... <IP_ADDRESS>, 2620:1ec:bdf::45
Connecting to update.code.visualstudio.com (update.code.visualstudio.com)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://vscode.download.prss.microsoft.com/dbazure/download/stable/f1e16e1e6214d7c44d078b1f0607b2388f29d729/vscode-server-linux-legacy-x64.tar.gz [following]
--2024-07-30 11:46:17--  https://vscode.download.prss.microsoft.com/dbazure/download/stable/f1e16e1e6214d7c44d078b1f0607b2388f29d729/vscode-server-linux-legacy-x64.tar.gz
Resolving vscode.download.prss.microsoft.com (vscode.download.prss.microsoft.com)... <IP_ADDRESS>, 2606:2800:233:1cb7:261b:1f9c:2074:3c
Connecting to vscode.download.prss.microsoft.com (vscode.download.prss.microsoft.com)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 57745503 (55M) [application/octet-stream]
Saving to: ‘stable’

stable                                                      100%[=========================================================================================================================================>]  55,07M  27,9MB/s    in 2,0s

2024-07-30 11:46:19 (27,9 MB/s) - ‘stable’ saved [57745503/57745503]

wget seems also to ignore the timeout, so something really awkward is going on as the connection seems not to be refused or aborted, but it hangs for unknown reason.

Guessing there is a bigger issue, as when I just try visiting the insiders.vscode.dev site it either times out, or shows the below:

Still an issue @etkaar? Maybe you can try wget with the -v flag

Same issue since 9/11 update

Unfortunately this issue is still present, it's loading forever:

VS Code Version: 1.95.1
Commit: 65edc4939843c90c34d61f4ce11704f09d3e5cb6
Date: 2024-10-31T05:14:54.222Z
Electron: 32.2.1
ElectronBuildId: 10427718
Chromium: 128.0.6613.186
Node.js: 20.18.0
V8: 12.8.374.38-electron.0
OS: Windows_NT x64 10.0.19041
Remote - SSH Extension Version: v0.115.0
I have this issue for the xenial server and no problem for the jammy server.

And do you all see the same thing if you run the wget command manually? What is your network configuration like, are you behind a corporate proxy or something else that could mess with things?

If you get a chance to run the wget command manually, could you also try with and without the --read-timeout flag?  If that helps we can look into incorporating it.  On my machine that flag has a 900 seconds default timeout

@etkaar
While using the vscodeoffline project this happens to me.
Then I downloaded vscode-server for xenial and manually uploaded it to vscarts folder.
Remote-ssh extension used it and the problem was solved.
Are you trying remote-ssh connecting to the internet?

I also have the same problem and don't understand why there is no information on when this will be fixed? Does everything have to be blocked by Microsoft?


When rewriting paths, remove lineto segments that are redundant with a z command

Here's a reduced test case:
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 256 256">
  <path d="M20 20l80 80H20V20z"/>
</svg>

The penultimate V20 command draws to the same point as the origin, which is what z does anyway. Removing V20 should be safe.
There is a similar case when a redundant Lineto command directly follows a Moveto, like this:
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 256 256">
  <path d="M20 100V20a1 1 0 0 1 0 80z"/>
</svg>

In this case, if the initial Moveto is changed to M20 20 and the following V20 is removed, the rendering is identical.

Er, when I said "origin" in the original post, I meant the originating M command at the beginning — not 0,0

IIRC there are some cases when it’s needed, like some detail on stroke rendering. But yeah that’s a possible optimization.

Fair point. I'll make some test cases for shapes with strokes and see if I can identify what changes


Network Info Plus testing on Windows

What is your question?
Whenever I try to use a method from  Network Info Plus on Windows, I get the error:
MissingPluginException(No implementation found for method wifiName on channel dev.fluttercommunity.plus/network_info)
Is there some setup I should be doing before calling methods?

This is only for unit tests, if I build the flutter app it works ok, but would be nice to be able to run tests as well...