text:
circuit breaking exception

Good day everyone,
I am having a problem running ELK on docker.  After running for about 5 days; I start to receive circuit breaking exception errors.  This is a fresh install.  Below is a sample error from this morning:
[circuit_breaking_exception] [parent] Data too large, data for [<http_request>] would be [254981816/243.1mb], which is larger than the limit of [246546432/235.1mb], real usage: [254981816/243.1mb], new bytes reserved: [0/0b], usages [request=0/0b, fielddata=10250/10kb, in_flight_requests=0/0b, accounting=3859727/3.6mb], with { bytes_wanted=254981816 & bytes_limit=246546432 & durability="PERMANENT" }
Version: 7.6.0
Build: 29000
Error: Too Many Requests
at fetchResponse$ (http://x.x.x.x:5601/bundles/commons.bundle.js:3:2991052)
at s (http://x.x.x.x:5601/bundles/kbn-ui-shared-deps/kbn-ui-shared-deps.js:338:774546)
at Generator._invoke (http://x.x.x.x:5601/bundles/kbn-ui-shared-deps/kbn-ui-shared-deps.js:338:774299)
at Generator.forEach.e. [as next] (http://x.x.x.x:5601/bundles/kbn-ui-shared-deps/kbn-ui-shared-deps.js:338:774903)
at s (http://x.x.x.x:5601/bundles/kbn-ui-shared-deps/kbn-ui-shared-deps.js:338:774546)
at t (http://x.x.x.x:5601/bundles/kbn-ui-shared-deps/kbn-ui-shared-deps.js:338:775041)
at http://x.x.x.x:5601/bundles/kbn-ui-shared-deps/kbn-ui-shared-deps.js:338:775191
I am also running filebeat 7.6.2 with apache enabled.  I am running Docker version 18.09.1, build 4c52b90.  ELK on Docker is running on Debian 10.
I have no idea if it's related or not but I have disabled ML in the elastic config elasticsearch.yml with "xpack.ml.enabled: false".  Elastic fails to start otherwise.
Output for troubleshooting:
#docker system df -v
Images space usage:
REPOSITORY                                      TAG                 IMAGE ID            CREATED             SIZE                SHARED SIZE         UNIQUE SIZE         CONTAINERS
docker.elastic.co/logstash/logstash             7.6.0               799d4bde3bdd        2 months ago        805.1MB             203MB               602.1MB             1
docker.elastic.co/kibana/kibana                 7.6.0               b36db011e72c        2 months ago        1.007GB             203MB               804MB               1
docker.elastic.co/elasticsearch/elasticsearch   7.6.0               5d2812e0e41c        2 months ago        790.1MB             203MB               587.1MB             1
Containers space usage:
CONTAINER ID        IMAGE                      COMMAND                  LOCAL VOLUMES       SIZE                CREATED             STATUS              NAMES
2b8cadf62acb        docker-elk_logstash        "/usr/local/bin/dock…"   0                   7.48MB              5 days ago          Up 5 days           docker-elk_logstash_1
dd26fbde167e        docker-elk_kibana          "/usr/local/bin/dumb…"   0                   203MB               5 days ago          Up 5 days           docker-elk_kibana_1
14d7a219f81a        docker-elk_elasticsearch   "/usr/local/bin/dock…"   1                   529MB               5 days ago          Up 5 days           docker-elk_elasticsearch_1
Local Volumes space usage:
VOLUME NAME                LINKS               SIZE
docker-elk_elasticsearch   1                   1.761GB
Build cache usage: 0B
CACHE ID            CACHE TYPE          SIZE                CREATED             LAST USED           USAGE               SHARED
There are a lot of logs..
Here is a sample from kibana:
kibana_1         | {"type":"log","@timestamp":"2020-04-26T14:46:41Z","tags":["error","plugins","taskManager","taskManager"],"pid":6,"message":"Failed to poll for work: [circuit_breaking_exception] [parent] Data too large, data for [<http_request>] would be [258589284/246.6mb], which is larger than the limit of [246546432/235.1mb], real usage: [258585400/246.6mb], new bytes reserved: [3884/3.7kb], usages [request=0/0b, fielddata=10250/10kb, in_flight_requests=3884/3.7kb, accounting=4007645/3.8mb], with { bytes_wanted=258589284 & bytes_limit=246546432 & durability="PERMANENT" } :: {"path":"/.kibana_task_manager/_update_by_query","query":{"ignore_unavailable":true,"refresh":true,"max_docs":10,"conflicts":"proceed"},"body":"{\"query\":{\"bool\":{\"must\":[{\"term\":{\"type\":\"task\"}},{\"bool\":{\"must\":[{\"bool\":{\"should\":[{\"bool\":{\"must\":[{\"term\":{\"task.status\":\"idle\"}},{\"range\":{\"task.runAt\":{\"lte\":\"now\"}}}]}},{\"bool\":{\"must\":[{\"bool\":{\"should\":[{\"term\":{\"task.status\":\"running\"}},{\"term\":{\"task.status\":\"claiming\"}}]}},{\"range\":{\"task.retryAt\":{\"lte\":\"now\"}}}]}}]}},{\"bool\":{\"should\":[{\"exists\":{\"field\":\"task.schedule\"}},{\"bool\":{\"must\":[{\"term\":{\"task.taskType\":\"actions:.server-log\"}},{\"range\":{\"task.attempts\":{\"lt\":1}}}]}},{\"bool\":{\"must\":[{\"term\":{\"task.taskType\":\"actions:.slack\"}},{\"range\":{\"task.attempts\":{\"lt\":1}}}]}},{\"bool\":{\"must\":[{\"term\":{\"task.taskType\":\"actions:.email\"}},{\"range\":{\"task.attempts\":{\"lt\":1}}}]}},{\"bool\":{\"must\":[{\"term\":{\"task.taskType\":\"actions:.index\"}},{\"range\":{\"task.attempts\":{\"lt\":1}}}]}},{\"bool\":{\"must\":[{\"term\":{\"task.taskType\":\"actions:.pagerduty\"}},{\"range\":{\"task.attempts\":{\"lt\":1}}}]}},{\"bool\":{\"must\":[{\"term\":{\"task.taskType\":\"actions:.webhook\"}},{\"range\":{\"task.attempts\":{\"lt\":1}}}]}},{\"bool\":{\"must\":[{\"term\":{\"task.taskType\":\"alerting:siem.signals\"}},{\"range\":{\"task.attempts\":{\"lt\":3}}}]}},{\"bool\":{\"must\":[{\"term\":{\"task.taskType\":\"vis_telemetry\"}},{\"range\":{\"task.attempts\":{\"lt\":3}}}]}},{\"bool\":{\"must\":[{\"term\":{\"task.taskType\":\"lens_telemetry\"}},{\"range\":{\"task.attempts\":{\"lt\":3}}}]}}]}}]}}]}},\"sort\":{\"_script\":{\"type\":\"number\",\"order\":\"asc\",\"script\":{\"lang\":\"painless\",\"source\":\"\\nif (doc['task.retryAt'].size()!=0) {\\n  return doc['task.retryAt'].value.toInstant().toEpochMilli();\\n}\\nif (doc['task.runAt'].size()!=0) {\\n  return doc['task.runAt'].value.toInstant().toEpochMilli();\\n}\\n    \"}}},\"seq_no_primary_term\":true,\"script\":{\"source\":\"ctx._source.task.ownerId=params.ownerId; ctx._source.task.status=params.status; ctx._source.task.retryAt=params.retryAt;\",\"lang\":\"painless\",\"params\":{\"ownerId\":\"kibana:ce42b997-a913-4d58-be46-bb1937feedd6\",\"status\":\"claiming\",\"retryAt\":\"2020-04-26T14:47:11.864Z\"}}}","statusCode":429,"response":"{\"error\":{\"root_cause\":[{\"type\":\"circuit_breaking_exception\",\"reason\":\"[parent] Data too large, data for [<http_request>] would be [258589284/246.6mb], which is larger than the limit of [246546432/235.1mb], real usage: [258585400/246.6mb], new bytes reserved: [3884/3.7kb], usages [request=0/0b, fielddata=10250/10kb, in_flight_requests=3884/3.7kb, accounting=4007645/3.8mb]\",\"bytes_wanted\":258589284,\"bytes_limit\":246546432,\"durability\":\"PERMANENT\"}],\"type\":\"circuit_breaking_exception\",\"reason\":\"[parent] Data too large, data for [<http_request>] would be [258589284/246.6mb], which is larger than the limit of [246546432/235.1mb], real usage: [258585400/246.6mb], new bytes reserved: [3884/3.7kb], usages [request=0/0b, fielddata=10250/10kb, in_flight_requests=3884/3.7kb, accounting=4007645/3.8mb]\",\"bytes_wanted\":258589284,\"bytes_limit\":246546432,\"durability\":\"PERMANENT\"},\"status\":429}"}"}
Here is a sample from elasticsearch:
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:47:39,041Z", "level": "DEBUG", "component": "o.e.a.s.TransportSearchAction", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[.monitoring-logstash-7-2020.04.26][0], node[K69CjFl1T2qpZR415TSkkA], [P], s[STARTED], a[id=baIs73LgS9K2x4LshgB0_Q]: Failed to execute [SearchRequest{searchType=QUERY_THEN_FETCH, indices=[.monitoring-logstash-7-2020.04.21, .monitoring-logstash-7-2020.04.22, .monitoring-logstash-7-2020.04.23, .monitoring-logstash-7-2020.04.24, .monitoring-logstash-7-2020.04.25, .monitoring-logstash-7-2020.04.26], indicesOptions=IndicesOptions[ignore_unavailable=true, allow_no_indices=true, expand_wildcards_open=true, expand_wildcards_closed=false, allow_aliases_to_multiple_indices=true, forbid_closed_indices=false, ignore_aliases=false, ignore_throttled=false], types=[], routing='null', preference='null', requestCache=null, scroll=null, maxConcurrentShardRequests=0, batchedReduceSize=512, preFilterShardSize=128, allowPartialSearchResults=true, localClusterAlias=null, getOrCreateAbsoluteStartMillis=-1, ccsMinimizeRoundtrips=true, source={"size":0,"query":{"bool":{"filter":[{"term":{"cluster_uuid":{"value":"_6sbAXT6QwOI_uvkGSCsXw","boost":1.0}}},{"range":{"timestamp":{"from":"now-2m","to":null,"include_lower":true,"include_upper":true,"boost":1.0}}},{"term":{"type":{"value":"logstash_stats","boost":1.0}}}],"adjust_pure_negative":true,"boost":1.0}},"aggregations":{"group_by_logstash":{"terms":{"field":"logstash_stats.logstash.uuid","size":1000,"min_doc_count":1,"shard_min_doc_count":0,"show_term_doc_count_error":false,"order":[{"_count":"desc"},{"_key":"asc"}]},"aggregations":{"group_by_version":{"terms":{"field":"logstash_stats.logstash.version","size":1,"min_doc_count":1,"shard_min_doc_count":0,"show_term_doc_count_error":false,"order":[{"latest_report":"desc"},{"_key":"asc"}]},"aggregations":{"latest_report":{"max":{"field":"timestamp"}}}}}}}}}]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA" ,
elasticsearch_1  | "stacktrace": ["org.elasticsearch.transport.RemoteTransportException: [14d7a219f81a][172.18.0.4:9300][indices:data/read/search[phase/query]]",
elasticsearch_1  | "Caused by: org.elasticsearch.common.breaker.CircuitBreakingException: [parent] Data too large, data for [<agg [latest_report]>] would be [249343304/237.7mb], which is larger than the limit of [246546432/235.1mb], real usage: [249338184/237.7mb], new bytes reserved: [5120/5kb], usages [request=5120/5kb, fielddata=11025/10.7kb, in_flight_requests=0/0b, accounting=3859420/3.6mb]",
elasticsearch_1  | "at org.elasticsearch.indices.breaker.HierarchyCircuitBreakerService.checkParentLimit(HierarchyCircuitBreakerService.java:343) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.common.breaker.ChildMemoryCircuitBreaker.addEstimateBytesAndMaybeBreak(ChildMemoryCircuitBreaker.java:128) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.AggregatorBase.addRequestCircuitBreakerBytes(AggregatorBase.java:128) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.AggregatorBase.(AggregatorBase.java:108) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.metrics.MetricsAggregator.(MetricsAggregator.java:36) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.metrics.NumericMetricsAggregator.(NumericMetricsAggregator.java:33) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.metrics.NumericMetricsAggregator.(NumericMetricsAggregator.java:29) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.metrics.NumericMetricsAggregator$SingleValue.(NumericMetricsAggregator.java:40) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.metrics.MaxAggregator.(MaxAggregator.java:67) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.metrics.MaxAggregatorFactory.doCreateInternal(MaxAggregatorFactory.java:59) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.metrics.MaxAggregatorFactory.doCreateInternal(MaxAggregatorFactory.java:37) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.support.ValuesSourceAggregatorFactory.createInternal(ValuesSourceAggregatorFactory.java:50) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.AggregatorFactory.create(AggregatorFactory.java:225) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.AggregatorFactories.createSubAggregators(AggregatorFactories.java:187) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.AggregatorBase.(AggregatorBase.java:78) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.bucket.BucketsAggregator.(BucketsAggregator.java:47) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.bucket.DeferableBucketAggregator.(DeferableBucketAggregator.java:41) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.bucket.terms.TermsAggregator.(TermsAggregator.java:189) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.bucket.terms.AbstractStringTermsAggregator.(AbstractStringTermsAggregator.java:43) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.bucket.terms.GlobalOrdinalsStringTermsAggregator.(GlobalOrdinalsStringTermsAggregator.java:93) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.bucket.terms.TermsAggregatorFactory$ExecutionMode$2.create(TermsAggregatorFactory.java:316) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.bucket.terms.TermsAggregatorFactory.doCreateInternal(TermsAggregatorFactory.java:162) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.support.ValuesSourceAggregatorFactory.createInternal(ValuesSourceAggregatorFactory.java:50) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.AggregatorFactory.create(AggregatorFactory.java:225) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.AggregatorFactory.asMultiBucketAggregator(AggregatorFactory.java:239) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.bucket.terms.TermsAggregatorFactory.doCreateInternal(TermsAggregatorFactory.java:123) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.support.ValuesSourceAggregatorFactory.createInternal(ValuesSourceAggregatorFactory.java:50) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.AggregatorFactory.create(AggregatorFactory.java:225) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.AggregatorFactories.createSubAggregators(AggregatorFactories.java:187) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.AggregatorBase.(AggregatorBase.java:78) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.bucket.BucketsAggregator.(BucketsAggregator.java:47) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.bucket.DeferableBucketAggregator.(DeferableBucketAggregator.java:41) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.bucket.terms.TermsAggregator.(TermsAggregator.java:189) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.bucket.terms.AbstractStringTermsAggregator.(AbstractStringTermsAggregator.java:43) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.bucket.terms.GlobalOrdinalsStringTermsAggregator.(GlobalOrdinalsStringTermsAggregator.java:93) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.bucket.terms.TermsAggregatorFactory$ExecutionMode$2.create(TermsAggregatorFactory.java:316) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.bucket.terms.TermsAggregatorFactory.doCreateInternal(TermsAggregatorFactory.java:162) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.support.ValuesSourceAggregatorFactory.createInternal(ValuesSourceAggregatorFactory.java:50) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.AggregatorFactory.create(AggregatorFactory.java:225) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.AggregatorFactories.createTopLevelAggregators(AggregatorFactories.java:203) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.aggregations.AggregationPhase.preProcess(AggregationPhase.java:55) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.query.QueryPhase.execute(QueryPhase.java:133) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.SearchService.loadOrExecuteQueryPhase(SearchService.java:338) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.SearchService.executeQueryPhase(SearchService.java:358) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.search.SearchService.lambda$executeQueryPhase$1(SearchService.java:343) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.action.ActionListener.lambda$map$2(ActionListener.java:146) ~[elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.action.ActionListener$1.onResponse(ActionListener.java:63) [elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.action.ActionRunnable.lambda$supply$0(ActionRunnable.java:58) [elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.action.ActionRunnable$2.doRun(ActionRunnable.java:73) [elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) [elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.common.util.concurrent.TimedRunnable.doRun(TimedRunnable.java:44) [elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingAbstractRunnable.doRun(ThreadContext.java:692) [elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) [elasticsearch-7.6.0.jar:7.6.0]",
elasticsearch_1  | "at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]",
elasticsearch_1  | "at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]",
elasticsearch_1  | "at java.lang.Thread.run(Thread.java:830) [?:?]"] }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:47:40,098Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470292] overhead, spent [1s] collecting in the last [1.2s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:47:42,127Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470294] overhead, spent [767ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:47:44,144Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470296] overhead, spent [597ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:47:46,147Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470298] overhead, spent [582ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:47:51,150Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470303] overhead, spent [590ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:47:54,421Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470306] overhead, spent [671ms] collecting in the last [1.2s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:48:00,424Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470312] overhead, spent [634ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:48:04,428Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470316] overhead, spent [595ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:48:05,428Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470317] overhead, spent [683ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:48:14,471Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470326] overhead, spent [600ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:48:24,476Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470336] overhead, spent [612ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:48:34,481Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470346] overhead, spent [591ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:48:37,839Z", "level": "INFO", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470349] overhead, spent [634ms] collecting in the last [1.3s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:48:38,840Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470350] overhead, spent [783ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:48:39,841Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470351] overhead, spent [588ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:48:41,309Z", "level": "INFO", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470352] overhead, spent [622ms] collecting in the last [1.4s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:48:44,310Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470355] overhead, spent [596ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:48:45,311Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470356] overhead, spent [745ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:48:51,819Z", "level": "INFO", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470362] overhead, spent [575ms] collecting in the last [1.5s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:48:54,139Z", "level": "INFO", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470364] overhead, spent [576ms] collecting in the last [1.3s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:48:56,141Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470366] overhead, spent [598ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:49:01,143Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470371] overhead, spent [588ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:49:04,146Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470374] overhead, spent [701ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:49:06,602Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470376] overhead, spent [1.1s] collecting in the last [1.4s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:49:07,603Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470377] overhead, spent [590ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:49:14,151Z", "level": "INFO", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470383] overhead, spent [625ms] collecting in the last [1.5s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:49:24,168Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470393] overhead, spent [604ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:49:34,178Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470403] overhead, spent [599ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:49:38,180Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470407] overhead, spent [588ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:49:39,587Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470408] overhead, spent [1.2s] collecting in the last [1.4s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:49:42,116Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470410] overhead, spent [1.3s] collecting in the last [1.5s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:49:44,166Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470412] overhead, spent [585ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:49:46,168Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470414] overhead, spent [582ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:49:54,174Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470422] overhead, spent [699ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:49:55,691Z", "level": "INFO", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470423] overhead, spent [579ms] collecting in the last [1.5s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:50:01,694Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470429] overhead, spent [722ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:50:03,149Z", "level": "INFO", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470430] overhead, spent [571ms] collecting in the last [1.4s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:50:04,198Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470431] overhead, spent [647ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:50:14,224Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470441] overhead, spent [584ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:50:24,230Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470451] overhead, spent [594ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
elasticsearch_1  | {"type": "server", "timestamp": "2020-04-26T14:50:34,239Z", "level": "WARN", "component": "o.e.m.j.JvmGcMonitorService", "cluster.name": "docker-cluster", "node.name": "14d7a219f81a", "message": "[gc][470461] overhead, spent [614ms] collecting in the last [1s]", "cluster.uuid": "_6sbAXT6QwOI_uvkGSCsXw", "node.id": "K69CjFl1T2qpZR415TSkkA"  }
Cheers-

I'm not familiar with this exception, but I noticed it's logged at level DEBUG. Are you certain it's a real issue and not an absolutely normal internal exception?

I think you need to increase your heap size as described in https://github.com/deviantony/docker-elk/blob/master/README.md#how-to-specify-the-amount-of-memory-used-by-a-service.
We set it to a very low value by default so the stack can run on small hardware, but you will want to increase it for "production" use.

Yes, it's a real issue.  At this point, ELK is dead/unusable.  I cannot view any data within the dashboard.  At this very point in time, I cannot even login to Kibana as I get the following error:
{"statusCode":500,"error":"Internal Server Error","message":"[circuit_breaking_exception] [parent] Data too large, data for [<http_request>] would be [247831322/236.3mb], which is larger than the limit of [246546432/235.1mb], real usage: [247831080/236.3mb], new bytes reserved: [242/242b], usages [request=0/0b, fielddata=10250/10kb, in_flight_requests=242/242b, accounting=3915017/3.7mb], with { bytes_wanted=247831322 & bytes_limit=246546432 & durability="PERMANENT" }"}
This is reproduceable.  Just start the containers with docker-compose and send apache logs to elastic with filebeat and enable the filebeat apache dashboard.  Wait 4-5 days and these errors will appear.
I just saw your second post.  I will try to increase the heap size and will follow up.  Thank you for that.
Cheers-

@ChristopherClayden did it help?

@antoineco Good day!  Everything looks OK at this point.  But the issues typically did not start until day #5 and today is day #4.  Feel free to close this issue and I can request to reopen it if the issue occurs again; or we can wait a few more days to see what happens.  Cheers-

I'm fine keeping it open, just wanted to touch base :)

@antoineco Good day sir!  Day #9 and everything is running smoothly.  I think we can close this issue out.  If the issue presents itself again; I will reopen.  Thank you for your help, I appreciate it!  Cheers-

authors: ChristopherClayden antoineco

repo: deviantony/docker-elk


text:
Feature Request: Check if device supports Telephoto Camera

Following are the devices on which Telephoto Camera technology is featured:

iPhone7Plus
iPhone8Plus
iPhoneX
iPhoneXS
iPhoneXSMax

Nice one! Will probably implement this.

source: gharchive/issue

repo: devicekit/DeviceKit

license: MIT

license_type: permissive

license_source: github-api


text:
Ensure av runner always shutdown

Tiny patch to ensure the asv runner is shutdown even if, for some reason, the benchmark fails.

Merged, thanks

source: gharchive/pull-request

authors: FabioLuporini rhodrin

repo: devitocodes/devito


text:
Update README.md

Describe the problem this PR solves
fixes default timeout value
Features and behaviour
fixes default timeout value
Describe how it solves the problem
fixes default timeout value as it was originally wrong
Additional context

Ooops thanks @si458! 🙂

repo: devlato/async-wait-until


text:
#344: add generic list support to Property

Fixes: #344
Implements:

adjusted all methods to use getValue
adjusted getter and setters

Pull Request Test Coverage Report for Build 9205657420
Details

0 of 0   changed or added relevant lines in 0 files are covered.
77 unchanged lines in 10 files lost coverage.
Overall coverage decreased (-0.05%) to 59.475%

Files with Coverage Reduction
New Missed Lines
%

com/devonfw/tools/ide/property/StringProperty.java
1
83.33%

com/devonfw/tools/ide/property/CommandletProperty.java
1
81.82%

com/devonfw/tools/ide/commandlet/AbstractUpdateCommandlet.java
1
82.3%

com/devonfw/tools/ide/property/VersionProperty.java
1
70.0%

com/devonfw/tools/ide/property/EnumProperty.java
2
13.64%

com/devonfw/tools/ide/property/PathProperty.java
3
5.17%

com/devonfw/tools/ide/commandlet/Commandlet.java
10
64.37%

com/devonfw/tools/ide/cli/CliArgument.java
15
66.67%

com/devonfw/tools/ide/property/StringListProperty.java
17
30.61%

com/devonfw/tools/ide/property/Property.java
26
73.21%

Totals

Change from base Build 9176576832:
-0.05%

Covered Lines:
4654

Relevant Lines:
7540

💛  - Coveralls

Duplicate of PR #355

Can be closed.

authors: coveralls hohwille jan-vcapgemini

repo: devonfw/IDEasy


text:
Rename chapter: devon4net -> .net

Rename chapters in docs
devon4net -> .net

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.dolvie seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


text:
Swet ball revamp

Adds colours of swet ball for each swet. Different colours can still stack together; the colour is purely aesthetic. This system can be used for other items that have multiple stackable variants as well.
Swets now drop more swet balls the bigger they are.
Textures for purple, white and golden swet balls are placeholders. Once proper textures are made, this is ready to merge.

Fixes~ #391

Looking into switching to a colour provider. Do not merge

Swet balls now use a colour provider instead of predefined variants. Predefined variants can still be used for other items, and I gave the golden swet ball a different texture to demonstrate this. I'll remove it before merging. There's also a copy of the original blue swet ball texture, if anyone wants it. I will remove that shortly as well.

Swet balls now use a colour provider instead of predefined variants. Predefined variants can still be used for other items, and I gave the golden swet ball a different texture to demonstrate this. I'll remove it before merging. There's also a copy of the original blue swet ball texture, if anyone wants it. I will remove that shortly as well.

Also need to review the new item colours. They can be changed in the swet loot table json.

The stackable variant system now uses an nbt compount instead of an int, allowing more advanced customisation of variants.
The alternative texture for golden swet balls can now be specified independently of the colour, and the golden and purple swet balls are multicoloured, to demonstrate. I will remove this before merging. All swet balls can support up to three coloured layers; I may also remove this before merging.

Swet ball textures still need to be done, although personally I think they look quite nice

repo: devs-immortal/The-Aether


text:
【fc-core】build 增加环境检测

build 在不使用 docker 时会依赖本机环境进行构建，但是当用户环境未准备好时，报错信息对用户不友好，例如在构建 python 项目时，若没有安装 pip，则会出现如下报错：

期望在进行构建前检测增加环境检测动作，若环境没准备好，则对用户进行友好的提示。包括执行 s build -d 时，若本地环境中的 docker 未正常运行，也需要进行友好的提示。

这些检测最好抽象出来一个个方法，这样方便其他组件复用

如果 runtime 是 python3,  但是本地环境是python2.7,  这个时候它也可以是可以有  pip 的命令行工具的。 这个时候， 其实不应该只是单独检测 pip， python 的版本， 应该也是需要简单检测下的， 至少  2  和 3 两个大版本需要区分

优先支持如下几种环境检测：

nodejs
python
docker
java

将该能力放到 fc-common 组件 中
mr

待 fc 组件集成

后续集成一个重要的组件集成， 然后把 pr diff 贴在这里， 再列出来其他需要接入的子组件列表

s build 如果需要使用本地环境，需要检测一下  已经完成 待发布

build 使用本地环境检测机制已经发布

authors: git-qfzhang rsonghuster wss-git

repo: devsapp/fc


text:
AKS local registry cannot pull image http

What happened?
We use local registry and run command devspace deploy can build and push image is success but pod cannot pull image, We  deploy on AKS is not allow  pull image with http
What did you expect to happen instead?
How do we fix this problem?

Local Environment:

DevSpace Version: 6.3.0
Operating System: mac
ARCH of the OS: AMD64

Kubernetes Cluster:

Cloud Provider: azure
Kubernetes Version: 1.23.12

@bukton123 Thanks for reporting the issue. Do you know if your AKS cluster is using containerd as it's container runtime?

@bukton123 We hope you were able to resolve this issue.
In general, if your cluster is using containerd as its container runtime, which has a built-in exception for localhost as an insecure registry, it should not be necessary to configure localhost in the insecure-registries configuration.
While it might be possible to modify the nodes of your AKS cluster, it may make your cluster unsupported. The recommendation would be to use ACR instead of DevSpace's local registry. You can disable it by setting localRegistry.enabled to false, since it will be used if unset and the registry cannot be pushed to.
Please reopen if your cluster is using containerd and it still not allowing the local registry and we will take another look!

repo: devspace-sh/devspace


text:
Build avoidance mechanism

Is your feature request related to a problem?
Yes. Especially in CI environment, the build avoidance mechanism fails because of Dockerfile or build context.
Which solution do you suggest?

Use paths relative to the project in order to calculate the two different hash.
Compute the checksum of Dockerfile rather than a combination of mTime and size.

Overall, from what I saw in the code base, I feel like the two functions Directory and DirectoryExcludes in pkg/util/hash should call each other, in order to get a consistent way of hash (and Directory could get its own fast bool arg).
Moreover, the path of a Dockerfile should not impact at all its hash.
Which alternative solutions exist?
Add a CI flag in the code to change some mechanism like the build avoidance.
Additional context
My CI environment (on GitlabCI) have been changing path depending on the runner. Whereas some configuration on my side have mitigated this issue, I think Devspace’s cache should not have been broken by an absolute path.
Also, by default, pulling a repository changes the mTime on all the code base, thus invalidating Dockerfile hash. Even if this can be mitigated by some tricks, having Devspace implementing this by default could be great.
Using checksum and relative path by default for both Dockerfile hash and build context hash could be great (and maybe moving the fast boolean in the devspace.yaml configuration).
Thanks again for this awesome project.
I am open to create a PR after some discussion

I see there is not that much involvement on this issue.
But it creates important issue for our use case right now. Within our CI, we need to fix Dockerfile’s timestamp in order not to trigger shouldRebuild() function, due to this function internal mechanism.
I understand the complexity of the function and that a simple workaround on our side might not be the best long-term solution. Therefore, I'm considering the possibility of submitting a Pull Request that would improve the shouldRebuild() function.
However, given the multiple potential approaches to address this problem, I believe it would be beneficial for all if we could first discuss the possible implementations. This way, we can ensure that any changes align well with the overall design and do not unintentionally affect other parts of the project.
Looking forward to your thoughts on this.
Thanks.


text:
:four_leaf_clover: Proposal: Plugins Enhancement

What would you like to add? Why is this needed?
Background
This issue is used as a "series" or "epic", which is a summary, not specific to a certain plugin.
At the moment (May 18th, 2022) we've got 18 plugins. Most plugins "work" as expected, but there is still space for improvement. For example, the following aspects could be improved:

documentation: more background for the plugin, what it does, why use it (instead of other plugins/other ways to manage the same DevOps tool), usage example (might need some update since we release quite frequently), sample config, technical doc (for example, what's returned in the state, what's in the output), etc.
blog posts (can be either in English or Chinese): how to use a certain plugin of DevStream to manage a certain DevOps tool
code refactor: better variable naming, better code organization, shorter and more testable functions, shorter files, unit tests, functional tests (with Ginkgo), integrational tests (with GitHub actions e2e-test, run in a real EKS).
configuration: maybe the current config isn't straightforward for beginners to use. Better naming of keys could help. Maybe even the options structure can be improved, too. Also, adding default values, adding more critical options (think out of the box, think from the standpoint of a real user, instead of a developer of the plugin).

背景
这个问题是一个“系列”，可以被关联到具体的issues，而不是特指某个插件。
目前（2022 年 5 月 18 日）我们有 18 个插件。大多数插件按预期工作，但仍有改进空间。例如，可以改进以下方面：

文档：插件的更多背景，它的作用，为什么使用它（而不是其他插件/其他方式来管理相同的 DevOps 工具），使用示例（可能需要一些更新，因为我们发布频繁，可能目前的状态跟使用示例已经不一致了），配置示例，技术文档（例如，状态中返回的内容，输出中的内容）等。
博客文章（中英文均可）：如何使用DevStream的某个插件管理某个DevOps工具
代码重构：更好的变量命名、更好的代码组织、更短且更可测试的函数、更短的文件、单元测试、功能测试（使用 Ginkgo）、整合测试（使用 GitHub actions的e2e-test操作，在真实 k8s 环境中运行）。
配置：也许当前的配置对于初学者来说并不容易使用。更好地命名键可能会有所帮助。也许甚至选项结构也可以改进。此外，添加默认值，添加更多关键选项（跳出当前的sample config的限制思考，从真实用户的角度思考，而不是插件开发人员）。

blog posts (can be either in English or Chinese): how to use a certain plugin of DevStream to manage a certain DevOps tool
@IronCore864 Would the blogs be published on the devstream.io ?

i want to try

i want to try

@rxhuster please leave your comment under a specified sub-issue

authors: IronCore864 daniel-hutao rxhuster shubham-cmyk

repo: devstream-io/devstream


text:
ci-runner package upgrades

Summary
Update ci-runner underlying utilities, packages and docker version.
Motivation
ci-runner is using quite outdated packages and needs to be updated for security, performance and compatibility purpose.
Proposal
Update ci-runner underlying utilities, packages and docker version.

Duplicate of #1324

authors: anupdhiran prakarsh-dt

repo: devtron-labs/devtron


text:
Bug: External kubernetes secret environment not accessible.

📜 Description
External kubernetes secret is not accessible as env variables or volume.
👟 Reproduction steps

Add external kubernetes secret as configmap/secret in PRE/POST CD.
This kubernetes secret should have been accessible as env variable or volume in pre/post CD script but env variables are absent.

👍 Expected behavior
External kubernetes secret should have been accessible as env variable or volume.
👎 Actual Behavior
External kubernetes secret is not accessible as env variable or volume.
☸ Kubernetes version
KOps 1.22
Cloud provider

AWS

🌍 Browser
Chrome
🧱 Your Environment
No response
✅ Proposed Solution
In workflow manifest, envFrom configMapRef is not getting set.
👀 Have you spent some time to check if this issue has been raised before?

[X] I checked and didn't find any similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

RCA:- For pre/post CD we use argo workflow. In workflow manifest yaml we have to provide reference of configMap/secret under path "envFrom.configMapRef" and "envFrom.secretRef". We were not passing Kubernetes external secret name in workflow manifest so it was not accessible.


text:
Bug: Build stage configuration gets stuck if central-api is not reachable from client browser

📜 Description
Build stage configuration gets stuck if central-api is not reachable from client browser
👟 Reproduction steps

Setup devtron in an environment from where central api endpoint isn't accessible.
Try to setup your first workflow

👍 Expected behavior

It should allow everything without any issues

👎 Actual Behavior

It blocks saving the configuration and doesn't allow to edit anything and save button keeps loading for infinite time and then timeouts

☸ Kubernetes version
EKS 1.24
Cloud provider

AWS

🌍 Browser
Chrome
🧱 Your Environment
No response
✅ Proposed Solution
No response
👀 Have you spent some time to check if this issue has been raised before?

[X] I checked and didn't find any similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

AB#3905

Added a new state for handling scenario & unblocked users to save or update config that use I've docker file option. PR - https://github.com/devtron-labs/dashboard/pull/1086

authors: pawan-mehta-dt sohel-rp


text:
.Values.service.port not documented/undefined

This is not documented
https://github.com/dexidp/helm-charts/blob/e07a4ace80ee8f60011859b2b4880258ff71b1d6/charts/dex/templates/ingress.yaml#L3
Either document it or revert to
https://github.com/dexidp/helm-charts/blob/74bce57289cd80ecfd7d1a0cb12df0637ed44cba/charts/dex/templates/ingress.yaml#L3

Looks like the Ingress part of helm chart is broken due to last changes...

@lwj5 @ruzickap Should be fixed now.

authors: lwj5 ruzickap sagikazarmark

repo: dexidp/helm-charts


text:
Running nested queries fails?

Take the following code,
db_class.user.get(function (user) {
    if (!user.is_drag_and_drop_enabled) {
        db_class.user.update({
            is_drag_and_drop_enabled: 0
        }, function (updated) {});
    }
});

when it executes I get this error in the console,
dexie.js:1 Unhandled rejection: ReadOnlyError: Transaction is readonly
why is this?
It gets the data fine, I  #tested it by doing a console.log and it was showing the right data. The update function is this,
update: function (changes, callback) {
    return db.user.update(1, changes).then(function (updated) {
        return is_function(callback) ? callback(updated) : false;
    });
}

when I run the function outside of the get function, it works fine.

I assume you have your code surrounded by a transaction scope (inline or in a caller of your function) :
db.transaction('r',... () => {
    //your code here
}) ;

@dfahlander Out of curiosity, why is it like that?

It's becuase the indexedDB transaction was opened in a readonly state. For a full explanation of how transaction scopes work, read throw this doc page. I hope it explains the details: http://dexie.org/docs/Dexie/Dexie.transaction()

There is one thing that may trip people who are unaware of the details of how Dexie works. If they start a query that reads a table and during this query, start another query that modifies the database, they may run into ReadOnlyError: Transaction is readonly.
I ran into the issue with code that did a table.where(...).each(...) and the callback to .each() was changing the database. My immediate thought was "hmm.... I'm not using transactions" because I never call db.transaction explicitly, but the outer query does start a readonly transaction implicitly. And the code in .each() executes within that implicit transaction.

That's true. The issue is there's no way in indexedDB to upgrade a transaction to be readwrite. So there would be two options of solving this. Either do the things within each as separate transactions (which could  lead to performance issues), or better, provide a more explaining error message when each() is used transactionless. (Suggest using Collection.modify() instead, or use a 'rw' transaction scope around Collection.each())

authors: Script47 dfahlander lddubeau

license_source: bigquery


text:
ModifyError with 3.0.0-alpha.5

Started getting this ModifyError in certain spots in our app after updating to Dexie 3.0.0-alpha.5:
Error: Error modifying one or more objects. Errors: function () {
    return Promise.all(this);
}
    at http://localhost:9876/base/webpack.tests.js:66580:31
    at http://localhost:9876/base/webpack.tests.js:65722:23
    at callListener (http://localhost:9876/base/webpack.tests.js:65456:19)
    at endMicroTickScope (http://localhost:9876/base/webpack.tests.js:65528:25)
    at http://localhost:9876/base/webpack.tests.js:65587:17
    at FDBRequest.done [as onsuccess] (http://localhost:9876/base/webpack.tests.js:67444:21)
    at invokeEventListeners (http://localhost:9876/base/webpack.tests.js:73789:31)
    at FDBRequest../node_modules/fake-indexeddb/build/lib/FakeEventTarget.js.FakeEventTarget.dispatchEvent (http://localhost:9876/base/webpack.tests.js:73842:13)
From previous:
    at Promise$1.then (http://localhost:9876/base/webpack.tests.js:65223:22)
    at http://localhost:9876/base/webpack.tests.js:66578:37
    at http://localhost:9876/base/webpack.tests.js:65722:23
    at callListener (http://localhost:9876/base/webpack.tests.js:65456:19)
    at endMicroTickScope (http://localhost:9876/base/webpack.tests.js:65528:25)
    at http://localhost:9876/base/webpack.tests.js:65587:17
    at FDBRequest.req.onsuccess (http://localhost:9876/base/webpack.tests.js:67556:67)
    at invokeEventListeners (http://localhost:9876/base/webpack.tests.js:73789:31)
From previous:
    at Promise$1.then (http://localhost:9876/base/webpack.tests.js:65223:22)
    at nextChunk (http://localhost:9876/base/webpack.tests.js:66536:109)
    at http://localhost:9876/base/webpack.tests.js:66578:24
    at http://localhost:9876/base/webpack.tests.js:65722:23
    at callListener (http://localhost:9876/base/webpack.tests.js:65456:19)
    at endMicroTickScope (http://localhost:9876/base/webpack.tests.js:65528:25)
    at http://localhost:9876/base/webpack.tests.js:65587:17
    at FDBRequest.req.onsuccess (http://localhost:9876/base/webpack.tests.js:67556:67)
From previous:
    at Object.getMany (http://localhost:9876/base/webpack.tests.js:67585:24)
    at nextChunk (http://localhost:9876/base/webpack.tests.js:66536:38)
    at http://localhost:9876/base/webpack.tests.js:66578:24
    at http://localhost:9876/base/webpack.tests.js:65722:23
    at callListener (http://localhost:9876/base/webpack.tests.js:65456:19)
    at endMicroTickScope (http://localhost:9876/base/webpack.tests.js:65528:25)
    at http://localhost:9876/base/webpack.tests.js:65587:17
    at FDBRequest.req.onsuccess (http://localhost:9876/base/webpack.tests.js:67556:67)"

It's reproducible in our test suite (which is using FakeIndexedDB, hence the FDB stuff above), but I've also seen it in Chrome when running the app with real indexedDB.
This error seems to happen in a spot when we are calling this.$db.update(id, data).
There is another spot in the app where we call this.$db.put(data) and it seems to work with no problem.
I can try to dig in a bit deeper and provide more information if you let me know what would be useful.

Thanks for this report! Table.update() and Collection.modify() is totally rewritten to not use IDBCursor.update() but instead use IDBObjectStore.put().
If you have the possibility to run it when chrome developer tools is open with "pause on caught exception" turned on, to find where the exception or error event happens. Even if it is an error event, it is interseting what type of event it is. If it for example is a ConstraintError, it would be nice to re-run the code putting some console.log() in various places of Collection.modify() to see what is beeing send down to DBCore in the mutate() request.
(It is also strange that the errors property contains a function. That could be a clue for me so far, but that is probably another issue.)

Ahhhh, okay, setting breakpoints in Collection.modify() where it adds to the failures array allowed me to figure out what was going on.
There's a for (let pos in failures) loop in there that was looping over the empty array of failures. However, we'd added an awaitPromises method on Array.prototype that was getting picked up by that loop and being treated as a failure.
So the current fix for us is to make our awaitPromises hack non-enumerable, so it doesn't get picked up by the for...in loop, but it might be worth a check whether a standard for loop would be better here?

authors: dfahlander dpogue


text:
I don't know how to use this code

Thanks a lot for your work. But I don't know how to use this code, it does not like python main.py?

Hi, thank you for appreciating the code in this repository. The code that contains the layer to compute Wasserstein distances is in layers.py, and an example on how to use it is in the notebook sinkhorn.ipynb. Perhaps this could work as a guide to incorporate it into your own work.

authors: dfdazac heerduo

repo: dfdazac/wassdistance


text:
ReadMe & Changelog Redux

This turned out to be a much larger revision of the documentation than I was originally planning on, and once I got started I wanted to see it through. I split it into three separate commits.
First and foremost, I moved the Changelog to its own file, keeping only the most recent set of release notes in the ReadMe.
In the Changelog itself, I ended up falling down a rabbit hole of revising older notes to have more consistent syntax, and in the process, and part of that turned into moving the thank-yous to the top of each set of release notes wherever applicable.
Lastly, and most importantly, I added a Function Overview to the ReadMe, which did necessitate some minor revisions of the synopses of the help files.
There's a lot of other small tweaks here and there, too many to list, my apologies for that. I sincerely hope to see it used, because on several occasions, I found myself confused on how to use this module and didn't realize where the help files were. (I do know about Get-Help, but that required me to know the names of the functions to begin with.)
All I ask in return is that you do not ask for further revisions; I really don't want to touch this again, so use or modify whatever you see fit.
In regards to the work included in this PR, I formally waive any rights granted to me by the Apache-2.0 license. All of it may be applied to this project without my accreditation or further consent.

Thank you! Much appreciated. Will review. Documentation is definitely a challnge.

In hindsight I should've added a commit that included the unmodified changelog and then submitted my modifications in the next commit. Sorry about that.
Because GitHub's syntax highlighting is derping pretty hard on the markdown files, here are direct links to what they look like when rendered:
https://github.com/ImportTaste/ImportExcel/blob/readme-chlog_redux/CHANGELOG.md
https://github.com/ImportTaste/ImportExcel/blob/readme-chlog_redux/README.md

@jhoneill

Woops. The links to the function help files didn't have .md at the end. Fixed that.

Soon

Soon?

Was waiting for @jhoneill to get time to wire in the building of the help into the CI pipeline.

.

@dfinke Perhaps this could be merged now and the pipeline stuff could come later?

@dfinke Perhaps this could be merged now and the pipeline stuff could come later?
I really don't want to have to check recent commits and resolve conflicts again. This was supposed to be one-and-done.

Force pushes should be done now. I rebased everything entirely for a cleaner slate and clearer diffs.

Thanks for this. I don't want to keep kicking the can down the road on the CI update. There is lots on the plate at the moment. When I can, I'll look at incorporating this.

. . .

Thanks, appreciate the work on this. Closing it for now, will revisit when I have time. Other priorities are calling.

The readme of this project is too big to swallow. It's really hard to find the useful bits. I stumbled upon this issue and the proposed readme seems far better to me. Of course I could be missing hidden drawbacks.

authors: ImportTaste dfinke ndemou

repo: dfinke/ImportExcel


text:
Distinguish between server crashes and the internet not working.

Currently, if a candidates internet is down, we still show him the notification bar and even end the test after 1 minute. We should clearly mention to him that his internet is down.

Verified that this is done and merged it. We don't end the test if his internet is down. We do it only if the Gru server is down.

repo: dgraph-io/gru


text:
call api via javascript unauthorized (401)

hi, anyone success call api bearer authorization via angular-resource ?
I've tried from postman is no problem, but tried from angular is unauthorized and log is:
[GIN] 2017/01/05 - 14:54:57 | 401 |       9.967µs | ::1 |   OPTIONS /api/v1/stream/test Error #01: no token present in request
my setting header example controller:
func (ctrl StreamController) Stream(c *gin.Context) { 	c.Writer.Header().Set("Access-Control-Allow-Origin", "*") 	c.Writer.Header().Set("Access-Control-Allow-Headers", "Accept, Authorization") 	c.Writer.Header().Set("Access-Control-Allow-Methods", "GET, POST, OPTIONS,PUT,DELETE") 	c.Writer.Header().Set("Access-Control-Allow-Credentials", "true")
main package :
var secretString="secret" apiv1 := router.Group("api/v1") apiv1.Use(jwt.Auth(secretString)) apiv1.GET("/stream/:tag", streamController.Stream)
anyone solve the problem?

This is probably not the right place for asking for angular help.

authors: dgrijalva emildcorpse

repo: dgrijalva/jwt-go

license: mit


text:
Reduce size of "Give Love" feature or even give the option to hide it

Version and OS
0.45.7
Viewing on Chrome: 118.0.5993.124  on a Chromebook
Is your feature request related to a problem? Please describe.
I noticed that you added the "Give Love" widget. I appreciate the need and really want to support you. However, the widget completely takes over the top of the GUI which is disruptive. The screenshot in your PR looks different. Here is a screenshot.
It is particularly bothersome because it is always there even if I have given you all the kudos, which you deserve, I would add.
Describe the solution you'd like
There are two potential tiers of solutions and you could even do both:

Make it less intrusive so that it does not take up the entire top of the screen
Provide the ability to hide it (Maybe this is already there and I missed it?)

Thank you in advance for your consideration.

ahhh that is definitely a bug, it should only appear after clicking on a special icon

@jl-678 can you try flush browser cache? it definitely looks OK

And in the 'off' state

shift+f5/reload ?

you also dont tell anything about what platform you're running the actual software on, windows, mac, rPi, linux, some weird linux distro, docker, pip etc

My apologies for the lack of detail. I am running it on Docker on x86 in a docker compose configuration along with Playwright.
You are absolutely right. I loaded the page in both incognito and a separate browser and do not see this behavior. Hence, it is some kind of caching issue. Sorry. I will close this.


text:
This is another nonsense change to do a merge PR.

(Will be merge-squashed)

https://travis-ci.org/dhermes/ci-diff-helper/builds/166538357

repo: dhermes/ci-diff-helper


text:
Confusion about how to read the reservation vacancy table

Hi - Sorry for posting my off topic question in the other issue. I've spent a ton of time in the high sierra but never really bothered with the Yosemite system since it always confused me.
I was wondering if you could help me understand how to read the table of vacancies. Mainly I was wondering, are dates other than the 2-week-out date subject to lottery? For instance, if I wanted to submit a reservation for August 13 (1 available) or September 5 (4 available), are these bookable today (Aug 4)?
Apologies if my question is confusing. I'm trying to determine if it's worth it to work on a scraper to bypass the captcha or if it's the chances of getting any sort of permit through this system is low.

Yes it is confusing. Happy to share what I know, which at this point is a couple of years outdated.
The screenshot you post is of the "trailhead quota report". It shows vacancies that occur after the lottery for that start date has been drawn. The lottery is drawn 168 days in advance. That table will not show any dates more than 168 days in the future. This occurs when lottery winners cancel.

For instance, if I wanted to submit a reservation for August 13 (1 available) or September 5 (4 available), are these bookable today (Aug 4)?

Those vacancies are bookable by calling the reservation office. If they are still available when you call, then you can book over the phone and pay the fee with credit card (I think its perhaps $10).
As far as the walk-ups, my understanding is that those are day-of walk-ups. You go to the Yosemite permit office in person and then are eligible for a walk-up if there are any left for that day. If people don't show up for their permits, those also become available walk-up.
Does that clear things up?

Ah Thanks! That makes a lot more sense, thanks for clearing that up, I hadn't realize you could call in for bookings!

On Aug 4, 2020, at 6:36 PM, Daniel Himmelstein notifications@github.com wrote:

Yes it is confusing. Happy to share what I know, which at this point is a couple of years outdated.
The screenshot you post is of the "trailhead quota report". It shows vacancies that occur after the lottery for that start date has been drawn. The lottery is drawn 168 days in advance. That table will not show any dates more than 168 days in the future. This occurs when lottery winners cancel.
For instance, if I wanted to submit a reservation for August 13 (1 available) or September 5 (4 available), are these bookable today (Aug 4)?
Those vacancies are bookable by calling the reservation office. If they are still available when you call, then you can book over the phone and pay the fee with credit card (I think its perhaps $10).
As far as the walk-ups, my understanding is that those are day-of walk-ups. You go to the Yosemite permit office in person and then are eligible for a walk-up if there are any left for that day. If people don't show up for their permits, those also become available walk-up.
Does that clear things up?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

authors: apanagar dhimmel

repo: dhimmel/hackjohn


text:
yarn build:docs failing

My current setup
node -v && yarn --version
v18.15.0
3.3.1

Branch dev-0.8.0
The error message I'm receiving
yarn build:docs
Warning: You are running with an unsupported TypeScript version! This may work, or it might break. TypeDoc supports 4.0, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7
Error: packages/messaging/src/Message.ts:214:57 - error TS2554: Expected 0-1 arguments, but got 2.

214     throw new SDKErrors.DecodingMessageError(undefined, {
                                                            ~
215       cause: cause as Error,
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
216     })
    ~~~~~

Error: packages/modules/src/content/Content.ts:193:7 - error TS2554: Expected 0-1 arguments, but got 2.

193       { cause: errors }
          ~~~~~~~~~~~~~~~~~

Error: packages/modules/src/schema/Schema.chain.ts:58:7 - error TS2554: Expected 0-1 arguments, but got 2.

58       { cause }
         ~~~~~~~~~

Error: packages/modules/src/schema/Schema.ts:114:5 - error TS2554: Expected 0-1 arguments, but got 2.

114     { cause: errors }
        ~~~~~~~~~~~~~~~~~

Error: packages/utils/src/SDKErrors.ts:26:25 - error TS2304: Cannot find name 'ErrorOptions'.

26   constructor(options?: ErrorOptions) {
                           ~~~~~~~~~~~~

Error: packages/utils/src/SDKErrors.ts:29:7 - error TS2554: Expected 0-1 arguments, but got 2.

29       options
         ~~~~~~~

Error: packages/utils/src/SDKErrors.ts:138:38 - error TS2304: Cannot find name 'ErrorOptions'.

138   constructor(did: string, options?: ErrorOptions) {
                                         ~~~~~~~~~~~~

Error: packages/utils/src/SDKErrors.ts:139:44 - error TS2554: Expected 0-1 arguments, but got 2.

139     super(`Not a valid CORD DID "${did}"`, options)
                                               ~~~~~~~

Error: packages/utils/src/SDKErrors.ts:200:25 - error TS2304: Cannot find name 'ErrorOptions'.

200   constructor(options?: ErrorOptions) {
                            ~~~~~~~~~~~~

Error: packages/utils/src/SDKErrors.ts:203:7 - error TS2554: Expected 0-1 arguments, but got 2.

203       options
          ~~~~~~~

I able to replicate this issue,
For a case,
The SDKError class is defined as follows:
export class SDKError extends Error {
  constructor(...args: ConstructorParameters<ErrorConstructor>) {
    super(...args)
    this.name = this.constructor.name
  }
}

and we take one the class producing error BlockchainApiMissingError:
export class BlockchainApiMissingError extends SDKError {
  constructor(options?: ErrorOptions) {
    super(
      'The Chain API is not set. Did you forget to call `Cord.connect(…)` or `Cord.init(…)`?',
      options
    )
  }
}

we can remove options argument and it will work as expected.

I tried it on my local, same getting error
export class InvalidDidFormatError extends SDKError {
  constructor(did: string, options?: ErrorOptions) {
    super(`Not a valid CORD DID "${did}"`, options)
  }
}

where we are passing two argument it is giving the error.
but if we see defination any no. of argument are possible
export class SDKError extends Error {
  constructor(...args: ConstructorParameters<ErrorConstructor>) {
    super(...args)
    this.name = this.constructor.name
  }
}

authors: anmode roynrishingha


text:
[Feature]: minimalistic output

Description
Would be nice to have a config that makes the output way shorter, like feat: update variable names component.name or smth like this.
Suggested Solution
Feed short response examples to GPT to encourage it to stay concise
Alternatives
No response
Additional Context
No response

this should be possible with the latest version npm i -g opencommit@latest, turn off oco config set OCO_DESCRIPTION=false

@multipliedtwice does it help?

btw 3.0.12 is out, please npm i -g opencommit

authors: di-sukharev multipliedtwice

repo: di-sukharev/opencommit


text:
Update release.yml to use OIDC publishing

Fixes #36.

I've also removed the PYPI_TOKEN secret from this repo and the API token from PyPI.

repo: di/id


text:
Remove use of internal pip APIs

This PR fixes #13 ("Don't use pip's internal API"). It does so by using pip-api, which wrap's pip's command-line interface. Avoiding importing the internal API all together will ensure that this project is easier to maintain as pip changes, and will be more likely to support future versions, as the command-line interface changes much less frequently than the internal API.
As a result, it also fixes #17. Closes #18, closes #22, closes #28. (@jayvdb and @danie1k, thanks very much for these stop-gap PRs, but ultimately I think this is a more sustainable approach).

Nice job, I like pip_api :)

repo: di/pytest-reqs


text:
remove cat-maven-plugin

最新版本移除了这个，mvn cat:install 一直不成功，提示：
No plugin found for prefix 'cat' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local
需要怎么解决呢？谢谢

请按照首页最新的文档进行安装说明

repo: dianping/cat


text:
http://unidal.org/nexus/content/repositories/releases/ 这个仓库已经失效。

http://unidal.org这个域名已经过期了。。。

我一度以为是我改hosts文件覆盖了。弄了半天才发现域名过期了。。。不知道有没有大佬弄下，maven中心仓库也没有。

我install的时候也遇到了问题:
[ERROR] Failed to execute goal org.unidal.maven.plugins:codegen-maven-plugin:2.5.8:dal-model (generate data model) on project cat-client: Execution generate data model of goal org.unidal.maven.plugins:codegen-maven-plugin:2.5.8:dal-model failed: Plugin org.unidal.maven.plugins:codegen-maven-plugin:2.5.8 or one of its dependencies could not be resolved: Failed to collect dependencies at org.unidal.maven.plugins:codegen-maven-plugin:jar:2.5.8 -> org.unidal.maven.plugins:codegen:jar:2.5.8 -> org.unidal.framework:foundation-service:jar:3.1.0: Failed to read artifact descriptor for org.unidal.framework:foundation-service:jar:3.1.0: Could not transfer artifact org.unidal.framework:foundation-service:pom:3.1.0 from/to unidal.releases (http://unidal.org/nexus/content/repositories/releases/): Connect to unidal.org:80 [unidal.org/209.99.40.221] failed: Operation timed out (Connection timed out) -> [Help 1]

[ERROR] Plugin org.apache.maven.plugins:maven-clean-plugin:2.5 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-clean-plugin:jar:2.5: Could
not transfer artifact org.apache.maven.plugins:maven-clean-plugin:pom:2.5 from/to nexus-my (http://unidal.org/nexus/service/local/repositories/releases/content/): Connect to unidal.org:80 [unidal.org/209.99.40
.221] failed: Connection timed out: connect -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException

网络通了，域名应该续费了，效率给力


text:
Initialize project structure

添加docs目录
添加BeanFactory 和 SingletonBeanRegistry等类的UML设计方式

Error: HTTP Status 403 for request POST https://api.github.com/repos/dianpoint/summer/dependency-graph/snapshots
Error: Response body:
{
  "message": "Resource not accessible by integration",
  "documentation_url": "https://docs.github.com/rest/reference/dependency-graph#create-a-snapshot-of-dependencies-for-a-repository"
}
Error: Resource not accessible by integration
Error: HttpError: Resource not accessible by integration

repo: dianpoint/summer


text:
feat: server-side sorting for files

Sorting for the table on the homepage is now calculated server-side so it will sort through all files instead of just the ones visible on that page.
https://user-images.githubusercontent.com/14848722/230739044-51e76619-223a-44b9-82d9-bd17e6047bfc.mp4
the same can be implemented easily for the files page, but im not sure where to put the selection for that.

the same can be implemented easily for the files page, but im not sure where to put the selection for that.

It's fine for now, there's plans to move the table to the files page anyway.

authors: ItzDerock diced

repo: diced/zipline


text:
Edit Assets

When editing some asset the duration neither the start/end date are saved.

Hey @nsuva
yes - I noticed this today, too..
Do you work in my company and was in the meeting today? :D
I will check this and fix this ;)

Fixed https://github.com/didiatworkz/screenly-ose-monitor/releases/tag/v2.4

Hey @nsuva
I didn't see you comment...
For the next time open a new Issue, please.
You can rewrite the nginx config from screenly like this:
location /monitor {
	alias /var/www/html/monitor;
	try_files $uri $uri/ @monitor;

	location ~ \.php$ {
		include snippets/fastcgi-php.conf;
		fastcgi_param SCRIPT_FILENAME $request_filename;
		fastcgi_pass unix:/var/run/php/php7.3-fpm.sock;
	}
}

location @monitor {
	rewrite /monitor/(.*)$ /monitor/index.php?/$1 last;
}

location ~ \.php$ {
	include snippets/fastcgi-php.conf;
	fastcgi_pass unix:/var/run/php/php7.3-fpm.sock;
}

add this code to /etc/nginx/sites-enabled/screenly.conf before the last bracket }
Now you need the address: http://localhost/monitor/index.php
It is a quick and dirty solution.. For more information you can search for: PHP Apps in a Subdirectory in Nginx
Best,
didiatworkz

Thanks Mate !
Meanwhile I thought in something similar and have been testing. Will adapt it with the code you provided.
It seems to work and be able to use only one port for the reverse tunnel connection.
Thanks

authors: didiatworkz nsuva

repo: didiatworkz/screenly-ose-monitor


text:
How to add flow priors to VAE

Hello,
What would be the simplest way of replacing a Gaussian prior for VAE with a flow-based one?
Thanks

Hi,
I'd say the simplest would be to start from e.g. this example:
https://github.com/didriknielsen/survae_flows/blob/master/examples/mnist_vae.py
and add some bijective transformations after the VAE on line 50 (the layers are specified from data to latent, i.e. x -> z).
Alternatively, and equivalently, you can replace the base_distribution with a Flow.
Hope this helps. If it's not clear I post an example later.
Didrik

Thanks for your response, I had opted for the second option of replacing the base_distribution with a Flow. Much appreciated.

authors: DylanMannKrzisnik didriknielsen


text:
I use your circular_list and i have a question

Hi,
I use your circular_list and i would like to open a new route when i click on images,
i tried many things but didn't work, i would really appreciate it if u can lend me a hand.
ps: sorry my english is sooo poor x'(

there is an open issue about that inside the lib package https://github.com/DenisBogatirov/circle_wheel_scroll/issues/2

it's me again, sorry but i don't understand the post u linked i read it and do somes tests but that didn't work. Can u make me an sample please i use your basic circular_list/circular_list_page.dart i just want to click on every images to open a new pages.

I'm using this package https://pub.dev/packages/circle_wheel_scroll  and it
looks like doesn't have implemented onTap .
Diego Velásquez López
On Wed, Jun 26, 2019 at 11:37 AM Yuiie notifications@github.com wrote:

it's me again, sorry but i don't understand the post u linked i read it
and do somes tests but that didn't work. Can u make me an sample please i
use your basic circular_list/circular_list_page.dart i just want to click
on every images to open a new pages.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/diegoveloper/flutter-samples/issues/9?email_source=notifications&email_token=ABFL3UFYBFGT7FVTW55TTFLP4OLLBA5CNFSM4H3QUCM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYUDQGI#issuecomment-505952281,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABFL3UDX5SWYXMZ3TUELVLTP4OLLBANCNFSM4H3QUCMQ
.

oki thanks thats sad it was a nice widget

authors: Yuiie diegoveloper

repo: diegoveloper/flutter-samples


text:
[api] optimizing openapi specificatoin for client code generation

#9193
Optimizing the openapi specification for client code generation by (openapi-generator):

Removed some alias types, which are created for better doc rendered into HTML.
Removed enum definition for the type field, replaced with discriminator field for type has oneOf. Enum type generation has bug in rust language.
Always use camel case type name to ensure generated type / struct / class names are consistent.
Removed visibility enum value private, it is valid in Move, but we don't render private function.
Extract out XxxProperties type for the type has inline type definition (under allOf). This removes a type named XxxAllOf to be generated and generates XxxProperties instead.
update operationId fields to use underscore instead of hyphen, generated code will use operationId for method names, use underscore is more consistent with generated code. For languages prefer camel case, code generator will convert the format.
updated/added some field value examples

/land

repo: diem/diem


text:
[transactional-test-runner] Minor fixes #122_72

Motivation
minor fixes for transactional testing
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
cargo x check

/canary

:sunny: Canary successful

/land

:broken_heart: Test Failed - ci-test

/canary

/canary

:sunny: Canary successful

/land

authors: bors-diem sahithiacn

repo: diem/move


text:
Setting up the schema file according to diesel.toml when running embed_migrations! macro

Could the embed_migrations! macro also initialize the schema file as diesel migration run does?
Rust 1.27.2
Diesel 1.3 (both in Cargo.toml of my binary crate and diesel-cli itself).
In the changelog file it is said:

Fixed
diesel print-schema and infer_schema! now properly handle unsigned types in MySQL

Deprecated
diesel_infer_schema has been deprecated. diesel print-schema is now the only way to generate database schema. Diesel CLI can be configured to automatically regenerate your schema file when migrations are run. See diesel.rs/guides/configuring-diesel-cli for details.

But I still want to perform migrations automatically and to generate my schema file automatically also. If diesel migration run setup the schema, why embed_migrations! does not?

embed_migrations! is something that generates code at compile time, not an external tool that is run separately. Having that macro modify a file in your project as a side effect of being compiled would be extremely confusing. Not to mention that there's no guarantee that embed_migrations! will get compiled before src/schema.rs -- which would lead to a compiler error about code that doesn't exist.

@sgrif I am doing embed_migrations! in my build.rs so there is no problem at all to do that.

embed_migrations! is something that generates code at compile time, not an external tool that is run separately. Having that macro modify a file in your project as a side effect of being compiled would be extremely confusing.

This still applies to build.rs

Wow, that's sad news. Thank you for this link :(

Can I still have a file in src directory which includes contents from generated file in the target directory? According the link you posted, this will not violate any rules because the directory will remain unchanged.

authors: sgrif vityafx

repo: diesel-rs/diesel


text:
Add ability to document items of table! macro

This commit adds optinal syntax to the table! dsl to document the
generated code. It is now possible to add an doc-comment for the
generated module and for each column struct.
This should partially fix #378
cc @killercup

haven't read much of the code, but it currently fails on CI for this case:

error: no rules expected the token `{`
   --> src/macros/mod.rs:752:33
    |
748 |       table! {
    |  _____- starting here...
749 | |         use types::*;
750 | |         use macros::tests::my_types::*;
751 | |
752 | |         table_with_custom_types {
    | |                                 ^
753 | |             id -> Integer,
754 | |             my_type -> MyCustomType,
755 | |         }
756 | |     }
    | |_____- ...ending here: in this macro invocation

This is caused by the second rewriting rule that is used to parse the #[doc] attribute and place the content to the back. A similar error would pop up if we use the same syntax for the columns. (From a short view seems like it is very hard or even impossible to provide the /// syntax with the current implementation of the table! macro)
I'm a few weeks abroad, so I'm not able to work in this time on this. I will continue the development as soon as I returned. (Feel free to close the pull request in the mean time.)

I've changed the syntax to that one proposed by @killercup and fixed the failing test cases. This should be now ready to be merged.

Awesome! Thanks for sticking with this.
The diff looks pretty wild! Haven't read that much macro code in a while. I'll try to review it this evening. Maybe @Eijebong wants to have a look as well and play a round of "human substitution machine"? ;)
@sgrif did we ever talk about this? You might also have some thoughts on this (and the syntax I suggested).

Do you think you could add some compile-tests for valid and invalid syntax combinations? I'm not sure we have a comprehensive test suite for table!. It's a pretty complicated beast by now, and we should probably at least add tests for new features.

I've tried to add a compile fail macro for invalid syntax, but compile-test complains error: 0 unexpected errors found, 1 expected errors not found. It seems like that compile-test does not recognize error that originates outside of the tested crate.

This compile fail test works:
#[macro_use] extern crate diesel;

table! {
    /// User's table
    users {
        /// A user's ID
        id -> Integer,
    }
}

table! {
    12
    //~^ ERROR expected ident
}

fn main() {}

Maybe you can add this one with one more case for the explicit error thing you introduced. We can always add more tests later. (I'd add "compile-success" tests as more doc tests.)

For example the following code should trigger the explicit error I've introduced:
table! {
     some wrong syntax
}

Rustc prints the following error:
error: environment variable `invalid table! syntax` not defined
  --> src/lib.rs:59:1
   |
59 | / table!{
60 | |     some wrong syntax
61 | | }
   | |_^
   |
   = note: this error originates in a macro outside of the current crate

If I add this table! call to your compile-fail-test without an error annotation this test will still pass :(
(For the new syntax there should be at least 2 compile pass test. On doc test and one at the end of macros/mod.rs)

Okay, it seems compiletest is a bit fuzzy in what macro errors it finds or even looks for. This works for me:

one table! call per tests
exactly one "error-pattern" matcher below

For example:
#[macro_use] extern crate diesel;

table! {
     some wrong syntax
}
// error-pattern: invalid table! syntax

fn main() {}

and
#[macro_use] extern crate diesel;

table! {
    12
}
// error-pattern: expected ident

fn main() {}

Also, I just remembered something: You macro syntax allows all attributes, not just doc ones. Is this on purpose? Do we want that?
#[macro_use] extern crate diesel;

table! {
     #[foobar]
     posts {
         id -> Integer,
     }
}
// error-pattern: invalid table! syntax

fn main() {}

(This fails with "attribute foobar is currently unknown to the compiler" by the way.)

Okay, it seems compiletest is a bit fuzzy in what macro errors it finds or even looks for. This works for me:

one table! call per tests
exactly one "error-pattern" matcher below

This did not work for me. (I've added the first two as test cases, but the second one will fail:()

Also, I just remembered something: You macro syntax allows all attributes, not just doc ones. Is this on purpose? Do we want that?

This could be quite handy, because so you can also add things like #[allow(missing_docs)] to the generated code. (Maybe this should also be documented?)

This did not work for me.

Weird. It worked locally, but I'm using a newer nightly than the clippy CI target. Will check again later.

This could be quite handy, because so you can also add things like #[allow(missing_docs)] to the generated code. (Maybe this should also be documented?)

I'm not convinced we actually want that. It's not clear to the user where the attributes end up, and, more important, this macro should not be seen as something to generate Rust code (IMO), but as something that creates a mapping to "the SQL side".

I'm not convinced we actually want that. It's not clear to the user where the attributes end up, and, more important, this macro should not be seen as something to generate Rust code (IMO), but as something that creates a mapping to "the SQL side".

On the other hand this macro generates Rust code internally. So there is a possibility that someone manages to set warnings in such a way that the generated code does not compile(For example #[deny(missing_docs)] before this pull request).
There are two ways to handle this:

Allow to add those attributes to the generated code. Downside: Expose some underlying implementation details.
If such a warning is triggered fix that warning in the generated code. Downside: To fix an eventually occurring issue some time is needed (Implement the "fix", open a pull request, wait for review, wait till a new version containing those change is published).

(It should be no big problem to remove this, but I think this would be a quite helpful feature in some cases)

What is the way forward with this pull request? How do we want to handle the failing compile-fail test?

@killercup ping

Ah, thanks for the ping. So, from my side, nothing changed. Personally, I'd like to add this in a small, isolated increment. I.e, this PR should only allow doc comments in table! (and nothing else), with all the tests that come with that. I still don't think we should allow arbitrary attributes in this macro.
But this is just my opinion. What do you think, @Eijebong, @sgrif?
@weiznich, can you easily restrict this to only allow doc comments or is that much work? I'll try to look at the compiletest and hope I can get it to work.

Restricting this to doc comments should only require some small change. I think I must change the $doc:meta variables to $doc:expr and modify the parser from #[$doc] to #[doc=$doc].

@killercup Any news on the failing compile test?

Just had a look at the compile tests. They work for me.
Just like Travis, I'm running compiletest-rs 0.2.5 with
rustc 1.18.0-nightly (63c77214c 2017-04-24)
binary: rustc
commit-hash: 63c77214c1d38789652b465694b254205d1886e0
commit-date: 2017-04-24
host: x86_64-apple-darwin
release: 1.18.0-nightly
LLVM version: 3.9

Changing your second test to what I actually wrote above (with error-pattern) works:
#[macro_use] extern crate diesel;

table! {
     some wrong syntax
}
// error-pattern: invalid table! syntax

fn main() {}

The third one works as well with your latest changes and with this error matcher:
#[macro_use] extern crate diesel;

table! {
     #[foobar]
     //~^ ERROR expected ident, found #
     posts {
         id -> Integer,
     }
}

fn main() {}

Other than that, I still don't like the "environment variable invalid table! syntax not defined" message, and it's weird how big this PR is for this simple change. But, well…

Other than that, I still don't like the "environment variable invalid table! syntax not defined" message,

If there is a better way to produce an error message there, I'm happy to change this. But it seems like as long as compile_error is not implemented/stable that there is no better solution to achieve this. Without this message the macro will recuse endless.

it's weird how big this PR is for this simple change

To implement this change some bigger parts of the table!-macro parsing logic needed to be restructured. This results in the big diff :disappointed:
(Compile tests are fixed now, so this should be ready to merge)

One thing we need to ensure here is that we can extend the macro later to allow renames (yes, we want to have something #424 after all).

@killercup I've updated the pull request to address @sgrif comments.
As far as I could tell it should be quite easy to plug something like #424 into the "new" parsing structure, but I've not tried it…

Also I've found a small bug involving multi line doc comments on columns. This is fixed by the second commit.

authors: killercup weiznich


text:
Add boot mode in ironic properties

Add boot mode in Ironic properties

After adding the properties -
'capabilities': u'node:ceph-storage-0,cpu_vt:true,cpu_hugepages:true,boot_option:local,cpu_txt:true,cpu_aes:true,cpu_hugepages_1g:true,boot_mode:uefi',


text:
Customizing the render method

I can't seem to customize the report method from app>Exceptions>Handler.php like I should be able to. I suspect because all exceptions are being routed to the NewRelicExceptionHandler.php.
I need to modify the render method so that it returns json output instead of html output for http exceptions.
Is there a way around this without editing the NewRelicExceptionHandler.php file in the composer vendor package?

Never mind, I just had to change
$app->instance(
    Illuminate\Contracts\Debug\ExceptionHandler::class,
    new Nord\Lumen\ChainedExceptionHandler\ChainedExceptionHandler(
        **new Laravel\Lumen\Exceptions\Handler(),**
        [new Nord\Lumen\NewRelic\NewRelicExceptionHandler()]
    )
);

to the following
$app->instance(
    Illuminate\Contracts\Debug\ExceptionHandler::class,
    new Nord\Lumen\ChainedExceptionHandler\ChainedExceptionHandler(
        **new App\Exceptions\Handler(),**
        [new Nord\Lumen\NewRelic\NewRelicExceptionHandler()]
    )
);

@Hoya Please could you send a PR? Thanks!

Yeah I guess it could be clarified

Closing, PRs still welcome to clarify docs.

authors: Hoya Jalle19 hugovk

repo: digiaonline/lumen-newrelic


text:
Unhandled c2s stanza: iq; xmlns=urn:xmpp:mam:tmp

I'm using latest version of mod_mam on prosody and I'm seeing this error in logs.
stanzarouter                              debug	Unhandled c2s stanza: iq; xmlns=urn:xmpp:mam:tmp

You can see on mod_mam page that XEP-0313 has changed.
https://code.google.com/p/prosody-modules/wiki/mod_mam
I think this was already fixed for stanza.io: https://github.com/otalk/stanza.io/issues/42

+1 on this
Any chances for switching to stanza.io 7.x?

Switching to stanza.io 7.x is planned

Kaiwa now uses stanza.io 7

authors: manwe-pl sebu77 teodor-pripoae

repo: digicoop/kaiwa


text:
IGAPP-1033: Show contact information for pois

This pull request belongs to an issue on our bugtracker.
You can find it there by looking for an issue with the key which is mentioned in the title of this pull request.
It starts with the keyword IGAPP.

Why have you moved icons from "shelter" subfolder?

Because previously those where only used in web and are now used in native as well. Apart from that they are now not exclusively used for the shelter offer but also for pois, so I thought it makes no sense anymore to keep those in a shelter subfolder. Sooner or later it makes sense anyway to use the same icons on native and web (see https://issues.tuerantuer.org/browse/IGAPP-921).

repo: digitalfabrik/integreat-app


text:
IGAPP-1039: Remove inappbrowser patch

This pull request belongs to an issue on our bugtracker.
You can find it there by looking for an issue with the key which is mentioned in the title of this pull request.
It starts with the keyword IGAPP.

2. Opening external links is not working:  `[NotFoundError: The route https://www.github.com/digitalfabrik/integreat-app/ does not exist here.]`

Where is this? It works fine for me for other external links.

2. Opening external links is not working:  `[NotFoundError: The route https://www.github.com/digitalfabrik/integreat-app/ does not exist here.]`

Where is this? It works fine for me for other external links.

Test cms -> Testumgebung -> Willkommen

Tested on android emulator. neither can't open external links anymore. Weird that there is no issue yet for this on github repo ...

Can you perhaps test on a real device as it is working fine for me? Maybe it is an issue with android emulator?

Tested again with real devices, works fine.

@f1sh1918 @SteffiStuffel what to you want to do with this? I currently don't have time to investigate why it's not working on emulators anymore. Seems like this is the same issue: https://github.com/proyecto26/react-native-inappbrowser/issues/348

@f1sh1918 @SteffiStuffel what to you want to do with this? I currently don't have time to investigate why it's not working on emulators anymore. Seems like this is the same issue: proyecto26/react-native-inappbrowser#348

Either merge this and open a jira ticket with linking to the mentioned github issue, so we can fix this later / keep track of it
or close this PR, add a information to IGAPP-1039 and why it cannot be done currently. I prefer the first.

authors: SteffiStuffel steffenkleinle


text:
Feat: add 'Put Object ACL' node

This PR introduces a new "Put Object ACL" node that allows users to update the Access Control List (ACL) of an object within an S3 bucket.

@KIKOmanasijev thank you very much for your contribution!


text:
Feature: Add a Filter Option for Active and Expired contests

Is your feature request related to a problem? Please describe.
Currently, when I access the content section, I can only see Active contests and Expired challenges. This limitation restricts users from viewing past contests, which could be valuable for understanding trends and learning from previous challenges. Additionally, there is no option to filter between expired and upcoming contests, making it challenging to navigate through all available opportunities.
Showing all Active contests

Showing Expired challenges

Describe the solution you'd like
I would like the platform to implement a feature that allows users to see both expired contests and active ones in the content section. This means that when users open this section, they should be able to view all contests, regardless of their status.
Moreover, I propose adding a filter option that lets users easily manage what they see.
Filter Options: Users should have the ability to toggle between different views:
Active Contests Only: Show only contests that are currently open for participation.
Expired Contests Only: Show only contests that have already ended.
All Contests: Display both active and expired contests together.
This filter will enhance user experience by making it easier to find relevant contests based on their needs. Users will be able to quickly switch between viewing current opportunities and exploring past contests without having to sift through irrelevant information.
By implementing this feature, the platform will improve accessibility and usability, allowing users to make better-informed decisions about their participation in contests and challenges. Feel free to use this version as is or modify it further before submitting it!
Alternatives
No response
Additional Context
No response
Are you interested in contributing?

[ ] I'd like to work on this issue

Code of Conduct

[X] I have used the search function to check if an issue already exists
[X] I agree to follow this project's Code of Conduct

Which program are you contributing in?
Not applicable

@Symond1  Please assign this issue to me, I am happy to work on it.

@dhuruvandb, I appreciate your interest in working on this issue, but I don’t have access to assign it to you.

repo: digitomize/digitomize