[stable/mongodb-replicaset] 2nd Pod stuck at bootstrap/add to replicaset (replicas=3 in my case)

Is this a request for help?: Yes

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT

Version of Helm and Kubernetes:
Kubernetes (GKE):
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.7", GitCommit:"dd5e1a2978fd0b97d9b78e1564398aeea7e7fe92", GitTreeState:"clean", BuildDate:"2018-04-19T00:05:56Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.6-gke.2", GitCommit:"384b4eaa132ca9a295fcb3e5dfc74062b257e7df", GitTreeState:"clean", BuildDate:"2018-08-15T00:10:14Z", GoVersion:"go1.9.3b4", Compiler:"gc", Platform:"linux/amd64"}
Helm:
Client: &version.Version{SemVer:"v2.10.0", GitCommit:"9ad53aac42165a5fadc6c87be0dea6b115f93090", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.10.0", GitCommit:"9ad53aac42165a5fadc6c87be0dea6b115f93090", GitTreeState:"clean"}
Which chart:
stable/mongodb-replicaset
What happened:
Summary: 1st Pod started correct. 2nd Pod is stuck at "Init:2/3"
Details:
I wanna setup a mongodb replicaset with 3 replicas. I want to use authentication (secrets providing usernames / passwords already exists.) and TLS with X509 for authentication.
Here are the contents of my values.yaml file used for helm install:
replicas: 3
port: 27018

replicaSetName: rs0

podDisruptionBudget: {}
  # maxUnavailable: 1
  # minAvailable: 2

auth:
  enabled: true
  adminUser: admin
  adminPassword: pass1234
  metricsUser: metrics
  metricsPassword: pass1234
  key: abcdefghijklmnopqrstuvwxyz1234567890
  #existingKeySecret:
  #existingAdminSecret:
  #exisitingMetricsSecret:

# Specs for the Docker image for the init container that establishes the replica set
installImage:
  repository: k8s.gcr.io/mongodb-install
  tag: 0.6

  pullPolicy: IfNotPresent

# Specs for the MongoDB image
image:
  repository: mongo
  #tag: 3.6
  tag: latest
  pullPolicy: IfNotPresent

# Additional environment variables to be set in the container
extraVars: {}
# - name: TCMALLOC_AGGRESSIVE_DECOMMIT
#   value: "true"

# Prometheus Metrics Exporter
metrics:
  enabled: false
  image:
    repository: ssalaues/mongodb-exporter
    tag: 0.6.1
    pullPolicy: IfNotPresent
  port: 9216
  path: "/metrics"
  socketTimeout: 3s
  syncTimeout: 1m
  prometheusServiceDiscovery: true
  resources: {}

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

securityContext:
  runAsUser: 999
  fsGroup: 999
  runAsNonRoot: true

resources:
  limits:
  #   cpu: 100m
    memory: 512Mi
  requests:
#   cpu: 100m
    memory: 256Mi

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

affinity: {}

tolerations: []

extraLabels: {}

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

# Annotations to be added to the service
serviceAnnotations: {}

tls:
  # Enable or disable MongoDB TLS support
  enabled: true
  # Please generate your own TLS CA by generating it via:
  # $ openssl genrsa -out ca.key 2048
  # $ openssl req -x509 -new -nodes -key ca.key -days 10000 -out ca.crt -subj "/CN=mydomain.com"
  # After that you can base64 encode it and paste it here:
  # $ cat ca.key | base64 -w0
  cacert: base64 encoded ca certificate goes here
  cakey: base64 encoded ca key goes here

# Entries for the MongoDB config file
configmap:
  storage:
    dbPath: /data/db
  net:
    port: 27018
    ssl:
      mode: requireSSL
      CAFile: /data/configdb/tls.crt
      PEMKeyFile: /work-dir/mongo.pem
  replication:
    replSetName: rs0
  security:
    authorization: enabled
    clusterAuthMode: x509
    keyFile: /data/configdb/key.txt

# Readiness probe
readinessProbe:
  initialDelaySeconds: 5
  timeoutSeconds: 1
  failureThreshold: 3
  periodSeconds: 10
  successThreshold: 1

# Liveness probe
livenessProbe:
  initialDelaySeconds: 30
  timeoutSeconds: 5
  failureThreshold: 3
  periodSeconds: 10
  successThreshold: 1

I've installed the chart using:
helm install --name mongo-test -f values.yaml stable/mongodb-replicaset
helm installs first without any problems - no error messages during install:
NAME:   mongo-test
LAST DEPLOYED: Wed Aug 29 16:40:43 2018
NAMESPACE: b2c
STATUS: DEPLOYED

RESOURCES:
==> v1/Secret
NAME                                   TYPE               DATA  AGE
mongo-test-mongodb-replicaset-admin    Opaque             2     0s
mongo-test-mongodb-replicaset-ca       kubernetes.io/tls  2     0s
mongo-test-mongodb-replicaset-keyfile  Opaque             1     0s

==> v1/ConfigMap
NAME                                   DATA  AGE
mongo-test-mongodb-replicaset-init     1     0s
mongo-test-mongodb-replicaset-mongodb  1     0s
mongo-test-mongodb-replicaset-tests    1     0s

==> v1/Service
NAME                           TYPE       CLUSTER-IP  EXTERNAL-IP  PORT(S)    AGE
mongo-test-mongodb-replicaset  ClusterIP  None        <none>       27018/TCP  0s

==> v1beta2/StatefulSet
NAME                           DESIRED  CURRENT  AGE
mongo-test-mongodb-replicaset  3        1        0s

==> v1/Pod(related)
NAME                             READY  STATUS   RESTARTS  AGE
mongo-test-mongodb-replicaset-0  0/1    Pending  0         0s

NOTES:
1. After the statefulset is created completely, one can check which instance is primary by running:

    $ for ((i = 0; i < 3; ++i)); do kubectl exec --namespace b2c mongo-test-mongodb-replicaset-$i -- sh -c 'mongo --eval="printjson(rs.isMaster())"'; done

2. One can insert a key into the primary instance of the mongodb replica set by running the following:
    MASTER_POD_NAME must be replaced with the name of the master found from the previous step.

    $ kubectl exec --namespace b2c MASTER_POD_NAME -- mongo --eval="printjson(db.test.insert({key1: 'value1'}))"

3. One can fetch the keys stored in the primary or any of the slave nodes in the following manner.
    POD_NAME must be replaced by the name of the pod being queried.

    $ kubectl exec --namespace b2c POD_NAME -- mongo --eval="rs.slaveOk(); db.test.find().forEach(printjson)"

The 1st Pod is then started correctly and without any problems.
2nd Pod is stuck at "Init:2/3"
NAME                                          READY     STATUS     RESTARTS   AGE
po/mongo-test-mongodb-replicaset-0            1/1       Running    0          5m
po/mongo-test-mongodb-replicaset-1            0/1       Init:2/3   0          5m

when I connect to mongo-test-mongodb-replicaset-1 -c bootstrap I can find the following inside /work-dir/log.txt:
mongodb@mongo-test-mongodb-replicaset-1:/work-dir$ more log.txt
[2018-08-29T14:41:51,684293796+00:00] [on-start.sh] Bootstrapping MongoDB replica set member: mongo-test-mongodb-replicaset-1
[2018-08-29T14:41:51,687394595+00:00] [on-start.sh] Reading standard input...
[2018-08-29T14:41:51,688594499+00:00] [on-start.sh] Generating certificate
[2018-08-29T14:41:51,951181683+00:00] [on-start.sh] Peers: mongo-test-mongodb-replicaset-0.mongo-test-mongodb-replicaset.b2c.svc.cluster.local
[2018-08-29T14:41:51,952080311+00:00] [on-start.sh] Starting a MongoDB instance...
[2018-08-29T14:41:51,953075555+00:00] [on-start.sh] Waiting for MongoDB to be ready...
2018-08-29T14:41:52.020+0000 I CONTROL  [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2018-08-29T14:41:52.045+0000 I CONTROL  [initandlisten] MongoDB starting : pid=30 port=27017 dbpath=/data/db 64-bit host=mongo-test-mongodb-replicaset-1
2018-08-29T14:41:52.045+0000 I CONTROL  [initandlisten] db version v4.0.1
2018-08-29T14:41:52.045+0000 I CONTROL  [initandlisten] git version: 54f1582fc6eb01de4d4c42f26fc133e623f065fb
2018-08-29T14:41:52.045+0000 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.0.2g  1 Mar 2016
2018-08-29T14:41:52.045+0000 I CONTROL  [initandlisten] allocator: tcmalloc
2018-08-29T14:41:52.045+0000 I CONTROL  [initandlisten] modules: none
2018-08-29T14:41:52.045+0000 I CONTROL  [initandlisten] build environment:
2018-08-29T14:41:52.045+0000 I CONTROL  [initandlisten]     distmod: ubuntu1604
2018-08-29T14:41:52.045+0000 I CONTROL  [initandlisten]     distarch: x86_64
2018-08-29T14:41:52.045+0000 I CONTROL  [initandlisten]     target_arch: x86_64
2018-08-29T14:41:52.045+0000 I CONTROL  [initandlisten] options: { config: "/data/configdb/mongod.conf", net: { bindIp: "<IP_ADDRESS>", port: 27017, ssl: { CAFile: "/data/configdb/tls.crt", PEMKeyFile: "/work-dir/mongo.pem", mode: "requireSS
L" } }, replication: { replSet: "rs0" }, security: { authorization: "enabled", clusterAuthMode: "x509", keyFile: "/data/configdb/key.txt" }, storage: { dbPath: "/data/db" } }
2018-08-29T14:41:52.047+0000 I STORAGE  [initandlisten]
2018-08-29T14:41:52.047+0000 I STORAGE  [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2018-08-29T14:41:52.047+0000 I STORAGE  [initandlisten] **          See http://dochub.mongodb.org/core/prodnotes-filesystem
2018-08-29T14:41:52.048+0000 I STORAGE  [initandlisten] wiredtiger_open config: create,cache_size=1337M,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=jou
rnal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),
[2018-08-29T14:41:52,083645436+00:00] [on-start.sh] Retrying...
2018-08-29T14:41:52.789+0000 I STORAGE  [initandlisten] WiredTiger message [1535553712:789699][30:0x7fd33c091a00], txn-recover: Set global recovery timestamp: 0
2018-08-29T14:41:52.800+0000 I RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
2018-08-29T14:41:52.819+0000 I STORAGE  [initandlisten] createCollection: local.startup_log with generated UUID: 2a15f25a-5f7b-47d3-b1a3-2338677428d0
2018-08-29T14:41:52.832+0000 I FTDC     [initandlisten] Initializing full-time diagnostic data capture with directory '/data/db/diagnostic.data'
2018-08-29T14:41:52.833+0000 I STORAGE  [initandlisten] createCollection: local.replset.oplogTruncateAfterPoint with generated UUID: ae87a21f-d2dc-4474-b4de-d70d95b7a2a8
2018-08-29T14:41:52.847+0000 I STORAGE  [initandlisten] createCollection: local.replset.minvalid with generated UUID: ffaf5c08-356c-4ed0-b4e0-1b3d9cdeea92
2018-08-29T14:41:52.866+0000 I REPL     [initandlisten] Did not find local voted for document at startup.
2018-08-29T14:41:52.866+0000 I REPL     [initandlisten] Did not find local Rollback ID document at startup. Creating one.
2018-08-29T14:41:52.866+0000 I STORAGE  [initandlisten] createCollection: local.system.rollback.id with generated UUID: 6e3e4fc7-b821-4df6-9c32-7db2af4a3bc4
2018-08-29T14:41:52.880+0000 I REPL     [initandlisten] Initialized the rollback ID to 1
2018-08-29T14:41:52.880+0000 I REPL     [initandlisten] Did not find local replica set configuration document at startup;  NoMatchingDocument: Did not find replica set configuration document in local.system.replset
2018-08-29T14:41:52.881+0000 I CONTROL  [LogicalSessionCacheRefresh] Sessions collection is not set up; waiting until next sessions refresh interval: Replication has not yet been configured
2018-08-29T14:41:52.881+0000 I CONTROL  [LogicalSessionCacheReap] Sessions collection is not set up; waiting until next sessions reap interval: Replication has not yet been configured
2018-08-29T14:41:52.881+0000 I NETWORK  [initandlisten] waiting for connections on port 27017 ssl
2018-08-29T14:41:54.148+0000 I NETWORK  [listener] connection accepted from <IP_ADDRESS>:50022 #1 (1 connection now open)
2018-08-29T14:41:54.154+0000 I ACCESS   [conn1] note: no users configured in admin.system.users, allowing localhost access
2018-08-29T14:41:54.154+0000 I NETWORK  [conn1] received client metadata from <IP_ADDRESS>:50022 conn1: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "4.0.1" }, os: { type: "Linux", name: "Ub
untu", architecture: "x86_64", version: "16.04" } }
2018-08-29T14:41:54.157+0000 I ACCESS   [conn1] Unauthorized: not authorized on admin to execute command { endSessions: [ { id: UUID("95760764-878a-4dd0-8ce6-470182c48a3a") } ], $db: "admin" }
2018-08-29T14:41:54.158+0000 I NETWORK  [conn1] end connection <IP_ADDRESS>:50022 (0 connections now open)
[2018-08-29T14:41:54,162283712+00:00] [on-start.sh] Initialized.
[2018-08-29T14:41:54,267062979+00:00] [on-start.sh] Found master: mongo-test-mongodb-replicaset-0.mongo-test-mongodb-replicaset.b2c.svc.cluster.local
[2018-08-29T14:41:54,268004950+00:00] [on-start.sh] Adding myself (mongo-test-mongodb-replicaset-1.mongo-test-mongodb-replicaset.b2c.svc.cluster.local) to replica set...
2018-08-29T14:41:54.368+0000 I NETWORK  [listener] connection accepted from <IP_ADDRESS>:50550 #2 (1 connection now open)
2018-08-29T14:41:54.371+0000 I ACCESS   [conn2]  authenticate db: $external { authenticate: 1, mechanism: "MONGODB-X509", user: "CN=mongo-test-mongodb-replicaset-0", $db: "$external" }
2018-08-29T14:41:54.371+0000 I ACCESS   [conn2] Failed to authenticate CN=mongo-test-mongodb-replicaset-0@$external from client <IP_ADDRESS>:50550 with mechanism MONGODB-X509: UserNotFound: Could not find user CN=mongo-test-mongodb-repli
caset-0@$external
2018-08-29T14:41:54.372+0000 I NETWORK  [conn2] end connection <IP_ADDRESS>:50550 (0 connections now open)
2018-08-29T14:41:54.375+0000 I NETWORK  [listener] connection accepted from <IP_ADDRESS>:50552 #3 (1 connection now open)
2018-08-29T14:41:54.378+0000 I NETWORK  [conn3] received client metadata from <IP_ADDRESS>:50552 conn3: { driver: { name: "NetworkInterfaceTL", version: "4.0.1" }, os: { type: "Linux", name: "Ubuntu", architecture: "x86_64", version: "16
.04" } }
2018-08-29T14:41:54.379+0000 I ACCESS   [conn3]  authenticate db: $external { authenticate: 1, mechanism: "MONGODB-X509", user: "CN=mongo-test-mongodb-replicaset-0", $db: "$external" }
2018-08-29T14:41:54.379+0000 I ACCESS   [conn3] Failed to authenticate CN=mongo-test-mongodb-replicaset-0@$external from client <IP_ADDRESS>:50552 with mechanism MONGODB-X509: UserNotFound: Could not find user CN=mongo-test-mongodb-repli
caset-0@$external
[2018-08-29T14:41:57,388632734+00:00] [on-start.sh] Waiting for replica to reach SECONDARY state...
2018-08-29T14:41:57.441+0000 I NETWORK  [listener] connection accepted from <IP_ADDRESS>:50032 #4 (2 connections now open)
2018-08-29T14:41:57.446+0000 I NETWORK  [conn4] received client metadata from <IP_ADDRESS>:50032 conn4: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "4.0.1" }, os: { type: "Linux", name: "Ub
untu", architecture: "x86_64", version: "16.04" } }
2018-08-29T14:41:57.448+0000 I ACCESS   [conn4] Supported SASL mechanisms requested for unknown user 'admin@admin'
2018-08-29T14:41:57.448+0000 I ACCESS   [conn4] SASL SCRAM-SHA-1 authentication failed for admin on admin from client <IP_ADDRESS>:50032 ; UserNotFound: Could not find user admin@admin
2018-08-29T14:41:57.450+0000 I ACCESS   [conn4] Unauthorized: not authorized on admin to execute command { endSessions: [ { id: UUID("38098891-2b34-46eb-aef2-53a69416671f") } ], $db: "admin" }
2018-08-29T14:41:57.451+0000 I NETWORK  [conn4] end connection <IP_ADDRESS>:50032 (1 connection now open)
2018-08-29T14:41:58.504+0000 I NETWORK  [listener] connection accepted from <IP_ADDRESS>:50034 #5 (2 connections now open)
2018-08-29T14:41:58.508+0000 I NETWORK  [conn5] received client metadata from <IP_ADDRESS>:50034 conn5: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "4.0.1" }, os: { type: "Linux", name: "Ub
untu", architecture: "x86_64", version: "16.04" } }
2018-08-29T14:41:58.509+0000 I ACCESS   [conn5] Supported SASL mechanisms requested for unknown user 'admin@admin'
2018-08-29T14:41:58.510+0000 I ACCESS   [conn5] SASL SCRAM-SHA-1 authentication failed for admin on admin from client <IP_ADDRESS>:50034 ; UserNotFound: Could not find user admin@admin
2018-08-29T14:41:58.511+0000 I ACCESS   [conn5] Unauthorized: not authorized on admin to execute command { endSessions: [ { id: UUID("e1089881-4c47-450c-9721-6b291c6f0e50") } ], $db: "admin" }
2018-08-29T14:41:58.512+0000 I NETWORK  [conn5] end connection <IP_ADDRESS>:50034 (1 connection now open)
2018-08-29T14:41:59.574+0000 I NETWORK  [listener] connection accepted from <IP_ADDRESS>:50036 #6 (2 connections now open)
2018-08-29T14:41:59.582+0000 I NETWORK  [conn6] received client metadata from <IP_ADDRESS>:50036 conn6: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "4.0.1" }, os: { type: "Linux", name: "Ub
untu", architecture: "x86_64", version: "16.04" } }

Meanwhile the other - successfully started - pod mongo-test-mongodb-replicaset-0 has this entries in its logfile:
2018-08-29T14:41:22.973+0000 I CONTROL  [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2018-08-29T14:41:22.980+0000 I CONTROL  [initandlisten] MongoDB starting : pid=1 port=27017 dbpath=/data/db 64-bit host=mongo-test-mongodb-replicaset-0
2018-08-29T14:41:22.981+0000 I CONTROL  [initandlisten] db version v4.0.1
2018-08-29T14:41:22.981+0000 I CONTROL  [initandlisten] git version: 54f1582fc6eb01de4d4c42f26fc133e623f065fb
2018-08-29T14:41:22.981+0000 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.0.2g  1 Mar 2016
2018-08-29T14:41:22.981+0000 I CONTROL  [initandlisten] allocator: tcmalloc
2018-08-29T14:41:22.981+0000 I CONTROL  [initandlisten] modules: none
2018-08-29T14:41:22.981+0000 I CONTROL  [initandlisten] build environment:
2018-08-29T14:41:22.981+0000 I CONTROL  [initandlisten]     distmod: ubuntu1604
2018-08-29T14:41:22.981+0000 I CONTROL  [initandlisten]     distarch: x86_64
2018-08-29T14:41:22.981+0000 I CONTROL  [initandlisten]     target_arch: x86_64
2018-08-29T14:41:22.981+0000 I CONTROL  [initandlisten] options: { config: "/data/configdb/mongod.conf", net: { bindIp: "<IP_ADDRESS>", port: 27017, ssl: { CAFile: "/data/configdb/tls.crt", PEMKeyFile: "/work-dir/mongo.pem", mode: "requireSSL" } }, replication: { replSet: "rs0" }, security: { authorization: "enabled", clusterAuthMode: "x509", keyFile: "/data/configdb/key.txt" }, storage: { dbPath: "/data/db" } }
2018-08-29T14:41:22.982+0000 I STORAGE  [initandlisten] Detected data files in /data/db created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2018-08-29T14:41:22.982+0000 I STORAGE  [initandlisten]
2018-08-29T14:41:22.982+0000 I STORAGE  [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2018-08-29T14:41:22.982+0000 I STORAGE  [initandlisten] **          See http://dochub.mongodb.org/core/prodnotes-filesystem
2018-08-29T14:41:22.982+0000 I STORAGE  [initandlisten] wiredtiger_open config: create,cache_size=1337M,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),
2018-08-29T14:41:23.949+0000 I STORAGE  [initandlisten] WiredTiger message [1535553683:949243][1:0x7fee8d75da00], txn-recover: Main recovery loop: starting at 1/49280
2018-08-29T14:41:23.949+0000 I STORAGE  [initandlisten] WiredTiger message [1535553683:949915][1:0x7fee8d75da00], txn-recover: Recovering log 1 through 2
2018-08-29T14:41:24.043+0000 I STORAGE  [initandlisten] WiredTiger message [1535553684:43680][1:0x7fee8d75da00], txn-recover: Recovering log 2 through 2
2018-08-29T14:41:24.119+0000 I STORAGE  [initandlisten] WiredTiger message [1535553684:119960][1:0x7fee8d75da00], txn-recover: Set global recovery timestamp: 5b86b08600000004
2018-08-29T14:41:24.153+0000 I RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(1535553670, 4)
2018-08-29T14:41:24.153+0000 I STORAGE  [initandlisten] Triggering the first stable checkpoint. Initial Data: Timestamp(1535553670, 4) PrevStable: Timestamp(0, 0) CurrStable: Timestamp(1535553670, 4)
2018-08-29T14:41:24.165+0000 I STORAGE  [initandlisten] Starting WiredTigerRecordStoreThread local.oplog.rs
2018-08-29T14:41:24.166+0000 I STORAGE  [initandlisten] The size storer reports that the oplog contains 10 records totaling to 2325 bytes
2018-08-29T14:41:24.166+0000 I STORAGE  [initandlisten] Scanning the oplog to determine where to place markers for truncation
2018-08-29T14:41:24.209+0000 I FTDC     [initandlisten] Initializing full-time diagnostic data capture with directory '/data/db/diagnostic.data'
2018-08-29T14:41:24.211+0000 I REPL     [initandlisten] Rollback ID is 1
2018-08-29T14:41:24.211+0000 I REPL     [initandlisten] Recovering from stable timestamp: Timestamp(1535553670, 4) (top of oplog: { ts: Timestamp(1535553670, 4), t: 1 }, appliedThrough: { ts: Timestamp(0, 0), t: -1 }, TruncateAfter: Timestamp(0, 0))
2018-08-29T14:41:24.211+0000 I REPL     [initandlisten] Starting recovery oplog application at the stable timestamp: Timestamp(1535553670, 4)
2018-08-29T14:41:24.212+0000 I REPL     [initandlisten] No oplog entries to apply for recovery. Start point is at the top of the oplog.
2018-08-29T14:41:24.212+0000 I REPL     [replexec-0] New replica set config in use: { _id: "rs0", version: 1, protocolVersion: 1, writeConcernMajorityJournalDefault: true, members: [ { _id: 0, host: "mongo-test-mongodb-replicaset-0.mongo-test-mongodb-replicaset.b2c.svc.cluster.local:27017", arbiterOnly: false, buildIndexes: true, hidden: false, priority: 1.0, tags: {}, slaveDelay: 0, votes: 1 } ], settings: { chainingAllowed: true, heartbeatIntervalMillis: 2000, heartbeatTimeoutSecs: 10, electionTimeoutMillis: 10000, catchUpTimeoutMillis: -1, catchUpTakeoverDelayMillis: 30000, getLastErrorModes: {}, getLastErrorDefaults: { w: 1, wtimeout: 0 }, replicaSetId: ObjectId('5b86b0825d695f321fd3c7e6') } }
2018-08-29T14:41:24.213+0000 I REPL     [replexec-0] This node is mongo-test-mongodb-replicaset-0.mongo-test-mongodb-replicaset.b2c.svc.cluster.local:27017 in the config
2018-08-29T14:41:24.213+0000 I REPL     [replexec-0] transition to STARTUP2 from STARTUP
2018-08-29T14:41:24.213+0000 I NETWORK  [initandlisten] waiting for connections on port 27017 ssl
2018-08-29T14:41:24.213+0000 I REPL     [replexec-0] Starting replication storage threads
2018-08-29T14:41:24.214+0000 I REPL     [replexec-0] transition to RECOVERING from STARTUP2
2018-08-29T14:41:24.214+0000 I REPL     [replexec-0] Starting replication fetcher thread
2018-08-29T14:41:24.214+0000 I REPL     [replexec-0] Starting replication applier thread
2018-08-29T14:41:24.215+0000 I REPL     [replexec-0] Starting replication reporter thread
2018-08-29T14:41:24.214+0000 I NETWORK  [LogicalSessionCacheRefresh] Starting new replica set monitor for rs0/mongo-test-mongodb-replicaset-0.mongo-test-mongodb-replicaset.b2c.svc.cluster.local:27017
2018-08-29T14:41:24.215+0000 I NETWORK  [listener] connection accepted from <IP_ADDRESS>:37744 #2 (1 connection now open)
2018-08-29T14:41:24.216+0000 I REPL     [rsSync-0] Starting oplog application
2018-08-29T14:41:24.216+0000 I REPL     [rsSync-0] transition to SECONDARY from RECOVERING
2018-08-29T14:41:24.216+0000 I REPL     [rsSync-0] conducting a dry run election to see if we could be elected. current term: 1
2018-08-29T14:41:24.216+0000 I REPL     [replexec-0] dry election run succeeded, running for election in term 2
2018-08-29T14:41:24.218+0000 I REPL     [replexec-0] election succeeded, assuming primary role in term 2
2018-08-29T14:41:24.219+0000 I REPL     [replexec-0] transition to PRIMARY from SECONDARY
2018-08-29T14:41:24.219+0000 I REPL     [replexec-0] Entering primary catch-up mode.
2018-08-29T14:41:24.219+0000 I REPL     [replexec-0] Exited primary catch-up mode.
2018-08-29T14:41:24.219+0000 I REPL     [replexec-0] Stopping replication producer
2018-08-29T14:41:24.222+0000 I NETWORK  [conn2] received client metadata from <IP_ADDRESS>:37744 conn2: { driver: { name: "MongoDB Internal Client", version: "4.0.1" }, os: { type: "Linux", name: "Ubuntu", architecture: "x86_64", version: "16.04" } }
2018-08-29T14:41:24.222+0000 I NETWORK  [LogicalSessionCacheRefresh] Successfully connected to mongo-test-mongodb-replicaset-0.mongo-test-mongodb-replicaset.b2c.svc.cluster.local:27017 (1 connections now open to mongo-test-mongodb-replicaset-0.mongo-test-mongodb-replicaset.b2c.svc.cluster.local:27017 with a 5 second timeout)
2018-08-29T14:41:24.222+0000 W NETWORK  [LogicalSessionCacheRefresh] Unable to reach primary for set rs0
2018-08-29T14:41:24.723+0000 W NETWORK  [LogicalSessionCacheReap] Unable to reach primary for set rs0
2018-08-29T14:41:25.224+0000 W NETWORK  [LogicalSessionCacheReap] Unable to reach primary for set rs0
2018-08-29T14:41:25.724+0000 W NETWORK  [LogicalSessionCacheReap] Unable to reach primary for set rs0
2018-08-29T14:41:26.217+0000 I REPL     [rsSync-0] transition to primary complete; database writes are now permitted
2018-08-29T14:41:26.225+0000 I NETWORK  [listener] connection accepted from <IP_ADDRESS>:37748 #4 (2 connections now open)
2018-08-29T14:41:26.226+0000 I NETWORK  [listener] connection accepted from <IP_ADDRESS>:37750 #6 (3 connections now open)
2018-08-29T14:41:26.233+0000 I NETWORK  [conn6] received client metadata from <IP_ADDRESS>:37750 conn6: { driver: { name: "MongoDB Internal Client", version: "4.0.1" }, os: { type: "Linux", name: "Ubuntu", architecture: "x86_64", version: "16.04" } }
2018-08-29T14:41:26.233+0000 I NETWORK  [LogicalSessionCacheRefresh] Successfully connected to mongo-test-mongodb-replicaset-0.mongo-test-mongodb-replicaset.b2c.svc.cluster.local:27017 (1 connections now open to mongo-test-mongodb-replicaset-0.mongo-test-mongodb-replicaset.b2c.svc.cluster.local:27017 with a 0 second timeout)
2018-08-29T14:41:26.233+0000 I NETWORK  [conn4] received client metadata from <IP_ADDRESS>:37748 conn4: { driver: { name: "MongoDB Internal Client", version: "4.0.1" }, os: { type: "Linux", name: "Ubuntu", architecture: "x86_64", version: "16.04" } }
2018-08-29T14:41:26.234+0000 I NETWORK  [LogicalSessionCacheReap] Successfully connected to mongo-test-mongodb-replicaset-0.mongo-test-mongodb-replicaset.b2c.svc.cluster.local:27017 (2 connections now open to mongo-test-mongodb-replicaset-0.mongo-test-mongodb-replicaset.b2c.svc.cluster.local:27017 with a 0 second timeout)
2018-08-29T14:41:26.234+0000 I ACCESS   [conn6]  authenticate db: $external { authenticate: 1, mechanism: "MONGODB-X509", user: "CN=mongo-test-mongodb-replicaset-0", $db: "$external" }
2018-08-29T14:41:26.235+0000 I ACCESS   [conn6] Failed to authenticate CN=mongo-test-mongodb-replicaset-0@$external from client <IP_ADDRESS>:37750 with mechanism MONGODB-X509: UserNotFound: Could not find user CN=mongo-test-mongodb-replicaset-0@$external
2018-08-29T14:41:26.235+0000 I NETWORK  [LogicalSessionCacheRefresh] scoped connection to mongo-test-mongodb-replicaset-0.mongo-test-mongodb-replicaset.b2c.svc.cluster.local:27017 not being returned to the pool
2018-08-29T14:41:26.235+0000 I CONTROL  [LogicalSessionCacheRefresh] Sessions collection is not set up; waiting until next sessions refresh interval: Could not find user CN=mongo-test-mongodb-replicaset-0@$external
2018-08-29T14:41:26.235+0000 I ACCESS   [conn4]  authenticate db: $external { authenticate: 1, mechanism: "MONGODB-X509", user: "CN=mongo-test-mongodb-replicaset-0", $db: "$external" }
2018-08-29T14:41:26.236+0000 I ACCESS   [conn4] Failed to authenticate CN=mongo-test-mongodb-replicaset-0@$external from client <IP_ADDRESS>:37748 with mechanism MONGODB-X509: UserNotFound: Could not find user CN=mongo-test-mongodb-replicaset-0@$external
2018-08-29T14:41:26.236+0000 I NETWORK  [LogicalSessionCacheReap] scoped connection to mongo-test-mongodb-replicaset-0.mongo-test-mongodb-replicaset.b2c.svc.cluster.local:27017 not being returned to the pool
2018-08-29T14:41:26.236+0000 I CONTROL  [LogicalSessionCacheReap] Sessions collection is not set up; waiting until next sessions reap interval: Could not find user CN=mongo-test-mongodb-replicaset-0@$external
2018-08-29T14:41:26.236+0000 I NETWORK  [conn6] end connection <IP_ADDRESS>:37750 (2 connections now open)
2018-08-29T14:41:26.236+0000 I NETWORK  [conn4] end connection <IP_ADDRESS>:37748 (1 connection now open)
2018-08-29T14:41:30.295+0000 I NETWORK  [listener] connection accepted from <IP_ADDRESS>:52056 #7 (2 connections now open)
2018-08-29T14:41:30.300+0000 I NETWORK  [conn7] received client metadata from <IP_ADDRESS>:52056 conn7: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "4.0.1" }, os: { type: "Linux", name: "Ubuntu", architecture: "x86_64", version: "16.04" } }
2018-08-29T14:41:30.304+0000 I NETWORK  [conn7] end connection <IP_ADDRESS>:52056 (1 connection now open)
2018-08-29T14:41:40.300+0000 I NETWORK  [listener] connection accepted from <IP_ADDRESS>:52072 #8 (2 connections now open)
2018-08-29T14:41:40.304+0000 I NETWORK  [conn8] received client metadata from <IP_ADDRESS>:52072 conn8: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "4.0.1" }, os: { type: "Linux", name: "Ubuntu", architecture: "x86_64", version: "16.04" } }
2018-08-29T14:41:40.308+0000 I NETWORK  [conn8] end connection <IP_ADDRESS>:52072 (1 connection now open)
2018-08-29T14:41:50.293+0000 I NETWORK  [listener] connection accepted from <IP_ADDRESS>:52090 #9 (2 connections now open)
2018-08-29T14:41:50.297+0000 I NETWORK  [conn9] received client metadata from <IP_ADDRESS>:52090 conn9: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "4.0.1" }, os: { type: "Linux", name: "Ubuntu", architecture: "x86_64", version: "16.04" } }
2018-08-29T14:41:50.301+0000 I NETWORK  [conn9] end connection <IP_ADDRESS>:52090 (1 connection now open)
2018-08-29T14:41:54.219+0000 I NETWORK  [listener] connection accepted from <IP_ADDRESS>:49738 #10 (2 connections now open)
2018-08-29T14:41:54.224+0000 I NETWORK  [conn10] received client metadata from <IP_ADDRESS>:49738 conn10: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "4.0.1" }, os: { type: "Linux", name: "Ubuntu", architecture: "x86_64", version: "16.04" } }
2018-08-29T14:41:54.256+0000 I ACCESS   [conn10] Successfully authenticated as principal admin on admin
2018-08-29T14:41:54.261+0000 I NETWORK  [conn10] end connection <IP_ADDRESS>:49738 (1 connection now open)
2018-08-29T14:41:54.325+0000 I NETWORK  [listener] connection accepted from <IP_ADDRESS>:49740 #11 (2 connections now open)
2018-08-29T14:41:54.330+0000 I NETWORK  [conn11] received client metadata from <IP_ADDRESS>:49740 conn11: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "4.0.1" }, os: { type: "Linux", name: "Ubuntu", architecture: "x86_64", version: "16.04" } }
2018-08-29T14:41:54.362+0000 I ACCESS   [conn11] Successfully authenticated as principal admin on admin
2018-08-29T14:41:54.366+0000 I REPL     [conn11] replSetReconfig admin command received from client; new config: { _id: "rs0", version: 2, protocolVersion: 1, writeConcernMajorityJournalDefault: true, members: [ { _id: 0, host: "mongo-test-mongodb-replicaset-0.mongo-test-mongodb-replicaset.b2c.svc.cluster.local:27017", arbiterOnly: false, buildIndexes: true, hidden: false, priority: 1.0, tags: {}, slaveDelay: 0, votes: 1 }, { _id: 1.0, host: "mongo-test-mongodb-replicaset-1.mongo-test-mongodb-replicaset.b2c.svc.cluster.local" } ], settings: { chainingAllowed: true, heartbeatIntervalMillis: 2000, heartbeatTimeoutSecs: 10, electionTimeoutMillis: 10000, catchUpTimeoutMillis: -1, catchUpTakeoverDelayMillis: 30000, getLastErrorModes: {}, getLastErrorDefaults: { w: 1, wtimeout: 0 }, replicaSetId: ObjectId('5b86b0825d695f321fd3c7e6') } }
2018-08-29T14:41:54.372+0000 I NETWORK  [conn11] can't authenticate to mongo-test-mongodb-replicaset-1.mongo-test-mongodb-replicaset.b2c.svc.cluster.local:27017 as internal user, error: Could not find user CN=mongo-test-mongodb-replicaset-0@$external
2018-08-29T14:41:54.372+0000 I REPL     [conn11] replSetReconfig config object with 2 members parses ok
2018-08-29T14:41:54.372+0000 I ASIO     [Replication] Connecting to mongo-test-mongodb-replicaset-1.mongo-test-mongodb-replicaset.b2c.svc.cluster.local:27017
2018-08-29T14:41:54.380+0000 W REPL     [replexec-1] Got error (Unauthorized: command replSetHeartbeat requires authentication) response on heartbeat request to mongo-test-mongodb-replicaset-1.mongo-test-mongodb-replicaset.b2c.svc.cluster.local:27017; { ok: 1.0, hbmsg: "" }
2018-08-29T14:41:54.380+0000 E REPL     [conn11] replSetReconfig failed; NodeNotFound: Quorum check failed because not enough voting nodes responded; required 2 but only the following 1 voting nodes responded: mongo-test-mongodb-replicaset-0.mongo-test-mongodb-replicaset.b2c.svc.cluster.local:27017; the following nodes did not respond affirmatively: mongo-test-mongodb-replicaset-1.mongo-test-mongodb-replicaset.b2c.svc.cluster.local:27017 failed with command replSetHeartbeat requires authentication
2018-08-29T14:41:54.383+0000 I NETWORK  [conn11] end connection <IP_ADDRESS>:49740 (1 connection now open)
2018-08-29T14:41:58.387+0000 I NETWORK  [listener] connection accepted from <IP_ADDRESS>:52106 #14 (2 connections now open)
2018-08-29T14:41:58.391+0000 I NETWORK  [conn14] received client metadata from <IP_ADDRESS>:52106 conn14: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "4.0.1" }, os: { type: "Linux", name: "Ubuntu", architecture: "x86_64", version: "16.04" } }
2018-08-29T14:41:58.395+0000 I NETWORK  [conn14] end connection <IP_ADDRESS>:52106 (1 connection now open)
2018-08-29T14:42:00.407+0000 I NETWORK  [listener] connection accepted from <IP_ADDRESS>:52118 #15 (2 connections now open)
2018-08-29T14:42:00.416+0000 I NETWORK  [conn15] received client metadata from <IP_ADDRESS>:52118 conn15: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "4.0.1" }, os: { type: "Linux", name: "Ubuntu", architecture: "x86_64", version: "16.04" } }

from what I understand, everything goes well until the second mongo instance tries to become part of the replica set - when the primary tries to connect to the new cluster member, this connection fails and therefore the whole setup process is stuck
What you expected to happen:
Setup process should finish and successfully setup a replica set consisting of 3 (in this case) replicas.
How to reproduce it (as minimally and precisely as possible):
take my values.yaml and just run the helm install command (adapt names if needed)
Anything else we need to know:
I've also tried with Mongo 3.6 - same outcome.

seems not many people are facing this issue....I've also posted this problem over there on Stackoverflow - also zero response there

I think this is probably a Duplicate of #6522

I've also found #6522 but I think its a different issue. In #6522 they cant get any mongodb pod running at all.
My problem is that the second (and third) pods/mongodb's are not able to join the successfully created replicaset because there is something wrong about the user that is used to establish the connection.

+1
I am having the same issue.
2nd pod is stuck at the bootstrap init container, while 1st pod is up and running.
I not having this issue when auth was disabled.

I think its an issue, have the same problem

I'm also running into the same issue and I'm spending the day trying to debug it. Any luck or advice since posting this?

Opened up PR #7772 which is a simple fix to take care of this. We had this issue as well and was super annoying. Would appreciate hearing from others as well that this fix solves the issue.
Looks like @rmuehlbauer had the exact same issue that we did (you can find the Quorum check failed in the posted logs.

I can confirm - commenting out "clusterAuthMode: x509" prevents running into this problem but of course also disables x509 member authentication...
But maybe I have some kind of good news for you:
I think I've found the root cause for this issue.
During the init/bootstrap process x509 certificates are generated - those certificates are also used for member authentication in the replicaset.
The generated certificates are built with openssl and the subject parameter looks like "-subj "/CN=$my_hostname" (you can find this in "on-start.sh" line 90) - mongo documentation is saying the following about certificates used for member authentication:

"...Certificat Requirements: The Distinguished Name (DN), found in the member certificate’s subject, must specify a non-empty value for at least one of the following attributes: Organization (O), the Organizational Unit (OU) or the Domain Component (DC)."

(taken from: https://docs.mongodb.com/manual/tutorial/configure-x509-member-authentication/)
But wait - we only put a "CN=..." into our subject line!
So I changed the subject parameter in "on-start.sh" (line 90 again) to something like "-subj "/CN=$my_hostname/OU=it/O=your company" which makes the complete openssl command look like:
openssl req -new -key mongo.key -out mongo.csr -subj "/CN=$my_hostname/OU=it/O=your company" -config openssl.cnf
and fired up helm again (this time of course I'm using the locally patched chart for installation and not stable/mongodb-replicaset)
This time the chart worked liked intended - the replicaset was correctly bootstraped and in the end (in my case) there were 3 replicas up & running which are using x509 for membership and client authentication.
Maybe you guys could try and see if this hack also works in your case?

Well done, @rmuehlbauer - that makes sense and resolved the issue for me as well. Cheers! 🔥

I'm glad that this works also for you @TR-jboykin!
Next step would most likely be to neatly integrate the fix in all the scripts and config files of the helm chart.
I will try to have a look on this maybe next week - if someone else wants to volunteer, just go ahead :-)

Hi, I am having this same issue, but not using auth mode: 509x, it is user/password mode.
Using one shard and three replicas running on Kubernetes for long time it was running without any issue and suddenly container crashed and needed to restart the pod. after restarting the pod stacks at bootstrapping container for ever (since two days).
the primary has around 380 GB data and I see that the bootstraping container syncing as volume is increasing upto like 350GB and even more and then again start from 0GB.
MongoDB version 3.6
2020-07-09T10:10:08.360+0000 W NETWORK  [replSetDistLockPinger] Unable to reach primary for set config0
2020-07-09T10:10:08.360+0000 I NETWORK  [replSetDistLockPinger] Cannot reach any nodes for set config0. Please check network connectivity and the status of the set. This has happened for 491 checks in a row.
2020-07-09T10:10:08.360+0000 W SHARDING [replSetDistLockPinger] pinging failed for distributed lock pinger :: caused by :: ShutdownInProgress: Server is shutting down
2020-07-09T10:10:38.186+0000 W NETWORK  [ReplicaSetMonitor-TaskExecutor-0] Unable to reach primary for set config0
2020-07-09T10:10:38.213+0000 W NETWORK  [shard registry reload] Unable to reach primary for set config0
2020-07-09T10:10:38.213+0000 I SHARDING [shard registry reload] Periodic reload of shard registry failed  :: caused by :: ShutdownInProgress: could not get updated shard list from config server due to Server is shutting down; will retry after 30s
2020-07-09T10:10:38.236+0000 W NETWORK  [ReplicaSetMonitor-TaskExecutor-0] Unable to reach primary for set shard0
2020-07-09T10:10:38.361+0000 W NETWORK  [replSetDistLockPinger] Unable to reach primary for set config0
2020-07-09T10:10:38.361+0000 W SHARDING [replSetDistLockPinger] pinging failed for distributed lock pinger :: caused by :: ShutdownInProgress: Server is shutting down
2020-07-09T10:10:58.052+0000 I -        [repl writer worker 6]   xxxxxx.yyyy_5a0f4c64-dddf-4d59-94a7-0a7c93ab5bec collection clone progress: 780449/913793 85% (documents copied)


Completed Timeine onScroll Animation

Added the Timeline in Timelines folder .
Preview of the code .

https://user-images.githubusercontent.com/64985447/147371933-7cc68ba1-8672-4549-8145-c8f248f10220.mp4

I have done some corrections . Can you check once again please @nandini7637

@bhavesh-chaudhari  bro i checked it but it seems to be working properly . May be its an issue with screen height I guess. Can you please share me the screen height and width both at which things are getting messed ? and also the browser at which you checked.

@Abirpal202049
Added README.md
Preview of Readme >>
Timeline
 Tech Stack Used

Preview
https://user-images.githubusercontent.com/64985447/147418972-161e9e1f-8b75-49a9-bc33-274a6e30122a.mp4

@bhavesh-chaudhari bro i checked it but it seems to be working properly . May be its an issue with screen height I guess. Can you please share me the screen height and width both at which things are getting messed ? and also the browser at which you checked.

I think the issue is arising irrespective of the height. You can try checking responsiveness on some commonly used resolutions for devices like iphone, kindle fire, ipad, etc. I have checked on firefox and chrome. For ex:-

Please do let me know if i am mistaken somewhere. My suggestion is to try making it look consistent on most standard resolutions for mobile and tabs, so that this component becomes a complete solution on such timeline design. Happy Coding !

@bhavesh-chaudhari  bro I am still not getting the issue i tried testing it in chrome mozilla and brave . I you are free any time we can get to discord server o discuss about this .
https://user-images.githubusercontent.com/64985447/147486121-f2c9b5b0-1de5-438e-9066-b5688aed3a58.mp4

@sohan9819 Hey this seems great 👍  ! Actually there was some issue with my browser settings. Sorry for the inconvenience ! I have added alt to the images which was missing everything else seems fine. Approving this pr, thanks for the contribution.

@bhavesh-chaudhari  no problem bro . Thanks for the help 👍

What is your P.Id @sohan9819

I didn't understand 😅 ? @Abirpal202049

Participent Id

@Abirpal202049  sorry bro I dont know about participent id 😅. Can you tell me from where I can get it .


[PLATO-1671] - Standard Adobe Campaign Schema for Broad and Tracking Logs

Please link to the issue #…

@jishah-adobe please let us know once all the changes we discussed today are done and ready to be merged

I think the only thing really missing from this PR is that all the fields must be defined under a top level field named "xdm:directMarketing" or "xdm:marketing". Please take a look at the existing structure of ExperienceEvent and decide where these fields makes the most sense. - https://opensource.adobe.com/xdmVisualization/prod/master/uberschemas.experienceevent-generated.html

@ rding

@jishah-adobe  - Is this split into two separate field groups (Campaign Delivery Logs and Campaign Tracking Logs) because we  expect to have two different schema's

create a new PR with changes  https://github.com/adobe/xdm/pull/1362


tikv panic when tikv exit the import mode but import process is still not stopped during "import into" command is cancelled

Bug Report

What version of TiKV are you using?
master
What operating system and CPU are you using?

Steps to reproduce

set global tidb_enable_dist_task=off;
IMPORT INTO big.items  FROM "s3://tmp/9T-csv/big.items.*.csv?access-key=minioadmin&secret-access-key=minioadmin&endpoint=http%3a%2f%2f<IP_ADDRESS>%3a32762&force-path-style=true" with thread=16,detached;
cancel this job
clear table of big.items
set global tidb_enable_dist_task=on;
execute import into command again

What did you expect?
import job can be successfully
What did happened?
[2023/06/26 03:25:03.580 +00:00] [FATAL] [[lib.rs:497](http://lib.rs:497/)] ["[region 15563512] 15563513 ingest uuid: 5ACC4E816AC84B9682AA3E6985C3B924 range { start:<PHONE_NUMBER>000000FF665F698000000000FF000008014A6C3179FF6F616362FF456879FF7555526174FF517AFF7667316B5654FF64FF6646714B633253FFFF44397650414D446DFFFF436D7635466E55FF66FF32636C364249FF5775FF5042516472FF386642FF38555145FF57317630FF594A58FF56346D6146FF5738FF3536436B4D61FF53FF326E4568465470FFFF64726C6C564F4949FFFF354C3239316F54FF36FF73314B345246FF344AFF64704D7045FF376A52FF3252396CFF556F4A5AFF69646FFF4E76575546FF6979FF6F507A5A4C37FF33FF71724451683566FFFF5749795373574B48FFFF77566E6B35474BFF68FF33396E494875FF3958FF625A6B4769FF386955FF664B676AFF666D5875FF525049FF536261477AFF7773FF637A39506C63FF4AFF4B6D396C554143FFFF4955587951713571FFFF6A516D485A5557FF4AFF767230674865FF7243FF4767573468FF687234FF687A324CFF31776C47FF555471FF4C43436D30FF304BFF465379454878FF67FF3961674E486D68FFFF4C415A7633645749FFFF63524D6E464343FF66FF6C6567304536FF5856FF763853786DFF377134FF32586A54FF76446171FF655964FF4D48746D78FF314AFF53437857547AFF56FF6944776D654737FFFF6847485166333231FFFF76346B33494D68FF55FF3651726D3346FF6457FF3248587442FF4F6A6BFF784C6457FF77796D46FF704C36FF63714F4476FF7177FF645772693275FF31FF4D5A4967746F36FFFF516B70676A637445FFFF7144446C6C4149FF33FF72584E67434CFF7438FF3251504632FF745437FF63386A41FF6158434DFF4D6E69FF4935307259FF6236FF645970573658FF31FF75697A7A427352FFFF47315453755A3757FFFF6D334A30615934FF6CFF45646466455AFF4972FF6661324C48FF62526FFF4B357438FF54666145FF59396AFF5444774A35FF7233FF68654B556E78FF57FF514D30664D6664FFFF6B4F39446B435774FFFF4765796968356EFF4EFF79466D5A446CFF567AFF6575564A44FF4A556EFF5854544CFF546E4C4FFF667143FF4644535849FF3167FF746C357A754BFF4CFF707A3468715837FFFF6731526368445273FFFF6B7870524E3137FF65FF4E5041333547FF6D38FF5A7272494FFF516D66FF32646C6AFF49446D71FF554C75FF4E43756775FF5739FF61425568586AFF58FF567773364A5143FFFF6477513754594E4EFFFF574B7551657947FF42FF75784D5A4D42FF5579FF3647683356FF327867FF71335468FF41303168FF6F6337FF7945486974FF4B75FF327847396F45FF34FF39543550693257FFFF52687A314A484C31FFFF667332524B544AFF6AFF5A51766A4E44FF7441FF396577466BFF787968FF6A493875FF66385241FF386342FF4432516167FF6A75FF353474734838FF62FF36433856474559FFFF0000000000000000FFF7016E6F64653054FF3234FF497350516FFF4F556CFF4E305059FF61795973FF637578FF524F6E4E79FF4F73FF616273776353FF56FF354356346B6D53FFFF3668536551596743FFFF7171677464744BFF6EFF4D5346703047FF695AFF4948735672FF715536FF4443524FFF72494F4EFF673248FF38324C5A70FF5747FF446B76334F55FF39FF776F3571636242FFFF4247336974667332FFFF306F6561745056FF56FF5A7A344B7569FF3130FF4453704435FF4A6C6DFF4D553642FF37644D6FFF6D737AFF5468674F61FF5754FF55506A326264FF79FF3034674D536C57FFFF7272304279374E46FFFF35514D46523666FF64FF775641466A64FF4E4DFF7172434A5AFF627165FF616F3247FF5A343871FF676A45FF4473564F66FF4C00FF000000000000F800FE end:<PHONE_NUMBER>000000FF665F698000000000FF000008014A6E4D66FF34574B4EFF746E4AFF3078783263FF4850FF6A416778786CFF47FF426E456A527279FFFF3034353743715247FFFF71555438506E59FF49FF576736306B77FF574FFF6A61796959FF555236FF426F4643FF664C4875FF6E434FFF6D62794878FF304BFF544442704B67FF4BFF4C70504A69645AFFFF51636E6E414D5746FFFF3152587454694CFF6BFF69757341344FFF5036FF3245497665FF33366BFF6F4E5072FF336A5668FF7A7745FF7150556B66FF4579FF784F71496458FF4EFF613979546A7A4DFFFF454662456E394B30FFFF73736272447439FF4AFF786E3771556DFF7246FF3877325744FF4A326FFF4C415943FF6478566DFF327867FF4A38723378FF5367FF64497230624FFF49FF6637484C554863FFFF5A78594A57434843FFFF70395050686F4AFF6EFF74656D417971FF3850FF526D6E6F7AFF425258FF6E545331FF59706542FF487356FF3344555967FF4B62FF57644B7A496EFF30FF6372714C53354CFFFF6851515A5A796B6AFFFF78486C4D6F5A51FF57FF685A5870486DFF594DFF50585A5A62FF325346FF6F59496AFF73714F48FF634267FF56496E5347FF4546FF684B514E5144FF47FF4C424930614A72FFFF5A674C6D7136416EFFFF506F6444346935FF68FF334C79786E4AFF3365FF5342525551FF335379FF39495479FF566A5856FF386C48FF3350445365FF7A50FF43726D4C576BFF4DFF4B6B7067305778FFFF6D6A6C7534634856FFFF3976675051464BFF43FF34354C616B30FF5148FF776B436E45FF47546FFF61427432FF6B6B4342FF59714CFF4E7A4A736DFF514DFF50726D6E7432FF32FF325754776A5A6CFFFF4C4531596B6B4B6CFFFF4E616

tikv.log.gz

when import job is cancelled, status maybe not updated in time, import job will still running for a while, but at this time, tikv has been exit the import mode. this may lead to the panic

stack
[2023/06/25 11:10:23.597 +00:00] [FATAL] [lib.rs:497] ["[region 15563512] 15563513 ingest uuid: 5ACC4E816AC84B9682AA3E6985C3B924 range { start:<PHONE_NUMBER>000000FF665F698000000000FF000008014A6C3179FF6F6163
62FF456879FF7555526174FF517AFF7667316B5654FF64FF6646714B633253FFFF44397650414D446DFFFF436D7635466E55FF66FF32636C364249FF5775FF5042516472FF386642FF38555145FF57317630FF594A58FF56346D6146FF5738FF3536436B4D61
FF53FF326E4568465470FFFF64726C6C564F4949FFFF354C3239316F54FF36FF73314B345246FF344AFF64704D7045FF376A52FF3252396CFF556F4A5AFF69646FFF4E76575546FF6979FF6F507A5A4C37FF33FF71724451683566FFFF5749795373574B48FF
FF77566E6B35474BFF68FF33396E494875FF3958FF625A6B4769FF386955FF664B676AFF666D5875FF525049FF536261477AFF7773FF637A39506C63FF4AFF4B6D396C554143FFFF4955587951713571FFFF6A516D485A5557FF4AFF767230674865FF7243FF
4767573468FF687234FF687A324CFF31776C47FF555471FF4C43436D30FF304BFF465379454878FF67FF3961674E486D68FFFF4C415A7633645749FFFF63524D6E464343FF66FF6C6567304536FF5856FF763853786DFF377134FF32586A54FF76446171FF65
5964FF4D48746D78FF314AFF53437857547AFF56FF6944776D654737FFFF6847485166333231FFFF76346B33494D68FF55FF3651726D3346FF6457FF3248587442FF4F6A6BFF784C6457FF77796D46FF704C36FF63714F4476FF7177FF645772693275FF31FF
4D5A4967746F36FFFF516B70676A637445FFFF7144446C6C4149FF33FF72584E67434CFF7438FF3251504632FF745437FF63386A41FF6158434DFF4D6E69FF4935307259FF6236FF645970573658FF31FF75697A7A427352FFFF47315453755A3757FFFF6D33
4A30615934FF6CFF45646466455AFF4972FF6661324C48FF62526FFF4B357438FF54666145FF59396AFF5444774A35FF7233FF68654B556E78FF57FF514D30664D6664FFFF6B4F39446B435774FFFF4765796968356EFF4EFF79466D5A446CFF567AFF657556
4A44FF4A556EFF5854544CFF546E4C4FFF667143FF4644535849FF3167FF746C357A754BFF4CFF707A3468715837FFFF6731526368445273FFFF6B7870524E3137FF65FF4E5041333547FF6D38FF5A7272494FFF516D66FF32646C6AFF49446D71FF554C75FF
4E43756775FF5739FF61425568586AFF58FF567773364A5143FFFF6477513754594E4EFFFF574B7551657947FF42FF75784D5A4D42FF5579FF3647683356FF327867FF71335468FF41303168FF6F6337FF7945486974FF4B75FF327847396F45FF34FF395435
50693257FFFF52687A314A484C31FFFF667332524B544AFF6AFF5A51766A4E44FF7441FF396577466BFF787968FF6A493875FF66385241FF386342FF4432516167FF6A75FF353474734838FF62FF36433856474559FFFF0000000000000000FFF7016E6F6465
3054FF3234FF497350516FFF4F556CFF4E305059FF61795973FF637578FF524F6E4E79FF4F73FF616273776353FF56FF354356346B6D53FFFF3668536551596743FFFF7171677464744BFF6EFF4D5346703047FF695AFF4948735672FF715536FF4443524FFF
72494F4EFF673248FF38324C5A70FF5747FF446B76334F55FF39FF776F3571636242FFFF4247336974667332FFFF306F6561745056FF56FF5A7A344B7569FF3130FF4453704435FF4A6C6DFF4D553642FF37644D6FFF6D737AFF5468674F61FF5754FF55506A
326264FF79FF3034674D536C57FFFF7272304279374E46FFFF35514D46523666FF64FF775641466A64FF4E4DFF7172434A5AFF627165FF616F3247FF5A343871FF676A45FF4473564F66FF4C00FF000000000000F800FE end:<PHONE_NUMBER>000000FF665F69
8000000000FF000008014A6E4D66FF34574B4EFF746E4AFF3078783263FF4850FF6A416778786CFF47FF426E456A527279FFFF3034353743715247FFFF71555438506E59FF49FF576736306B77FF574FFF6A61796959FF555236FF426F4643FF664C4875FF6E
434FFF6D62794878FF304BFF544442704B67FF4BFF4C70504A69645AFFFF51636E6E414D5746FFFF3152587454694CFF6BFF69757341344FFF5036FF3245497665FF33366BFF6F4E5072FF336A5668FF7A7745FF7150556B66FF4579FF784F71496458FF4EFF
613979546A7A4DFFFF454662456E394B30FFFF73736272447439FF4AFF786E3771556DFF7246FF3877325744FF4A326FFF4C415943FF6478566DFF327867FF4A38723378FF5367FF64497230624FFF49FF6637484C554863FFFF5A78594A57434843FFFF7039
5050686F4AFF6EFF74656D417971FF3850FF526D6E6F7AFF425258FF6E545331FF59706542FF487356FF3344555967FF4B62FF57644B7A496EFF30FF6372714C53354CFFFF6851515A5A796B6AFFFF78486C4D6F5A51FF57FF685A5870486DFF594DFF50585A
5A62FF325346FF6F59496AFF73714F48FF634267FF56496E5347FF4546FF684B514E5144FF47FF4C424930614A72FFFF5A674C6D7136416EFFFF506F6444346935FF68FF334C79786E4AFF3365FF5342525551FF335379FF39495479FF566A5856FF386C48FF
3350445365FF7A50FF43726D4C576BFF4DFF4B6B7067305778FFFF6D6A6C7534634856FFFF3976675051464BFF43FF34354C616B30FF5148FF776B436E45FF47546FFF61427432FF6B6B4342FF59714CFF4E7A4A736DFF514DFF50726D6E7432FF32FF325754
776A5A6CFFFF4C4531596B6B4B6CFFFF4E616E784A4555FF31FF74354A58555AFF5750FF4D6C6C5A70FF78556FFF62777A7AFF534C3850FF753769FF7859354846FF3447FF5874754E3131FF32FF6F5A4D5549546BFFFF33416F6251485950FFFF4D51466873
586CFF6CFF494C7865574DFF6436FF6735714957FF554147FF34707174FF75483633FF366768FF4774784F52FF7262FF546868534666FF74FF5175507A4A5446FFFF3975473673706830FFFF4C63636D6C6868FF43FF486678593038FF6374FF5A3569344EFF
695147FF44584463FF51336755FF4A3650FF6E56356F30FF7061FF677833696937FF49FF4E6454334D7134FFFF6F41513575506C6BFFFF5A376467306541FF47FF4A5136503356FF7439FF50656B3976FF6D524EFF67566153FF71726C6BFF39584CFF4D6556
6C4AFF6474FF5648766C774FFF50FF45466C37505869FFFF6D64696469423470FFFF5350343956644EFF6DFF6C3063384635FF7073FF6374714353FF52444BFF65454569FF7A734278FF446752FF4A6549304CFF364AFF75593345354EFF4AFF386679645A41
69FFFF0000000000000000FFF7016E6F64653062FF357AFF6556444654FF49447AFF4B4A5472FF6473507AFF756546FF3377784163FF5A47FF636E784D5655FF47FF6C4A32674A344FFFFF657565574549376BFFFF70547471375034FF6FFF586B79563549FF
695147FF44584463FF51336755FF4A3650FF6E56356F30FF7061FF677833696937FF49FF4E6454334D7134FFFF6F41513575506C6BFFFF5A376467306541FF47FF4A5136503356FF7439FF50656B3976FF6D524EFF67566153FF71726C6BFF39584CFF4D6556
6C4AFF6474FF5648766C774FFF50FF45466C37505869FFFF6D64696469423470FFFF5350343956644EFF6DFF6C3063384635FF7073FF6374714353FF52444BFF65454569FF7A734278FF446752FF4A6549304CFF364AFF75593345354EFF4AFF386679645A41
69FFFF0000000000000000FFF7016E6F64653062FF357AFF6556444654FF49447AFF4B4A5472FF6473507AFF756546FF3377784163FF5A47FF636E784D5655FF47FF6C4A32674A344FFFFF657565574549376BFFFF70547471375034FF6FFF586B79563549FF
4A46FF70376E4A34FF4F4A49FF476D417AFF33506869FF454870FF44344C6270FF4274FF335047637241FF70FF7835794138614EFFFF62546B45334A414AFFFF77375357526143FF52FF537854763933FF4653FF6C546B724CFF33744DFF6A464563FF316532
4DFF6C654EFF42386E5572FF4850FF564665494B57FF34FF4C386557766357FFFF7567635752723943FFFF68584657414E72FF4AFF556E4C4C4748FF5747FF4A39545173FF765241FF46686F64FF42746B70FF693655FF7448647351FF6900FF000000000000
F800FE } cf_name: \"write\" region_id: 15563512 region_epoch { conf_ver: 47 version: 734 }: EngineTraits(Engine(Status { code: IoError, sub_code: None, sev: NoError, state: \"IO error: No such file or dir
ectory: while stat a file for size: /var/lib/tikv/data/import/5acc4e81-6ac8-4b96-82aa-3e6985c3b924_15563512_47_734_write.sst: No such file or directory\" }))"] [backtrace="   0: tikv_util::set_panic_hook:
:{{closure}}
             at home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tikv/components/tikv_util/src/lib.rs:496:18
   1: <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args
>>::call
             at rust/toolchains/nightly-2022-11-15-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:2032:9
      std::panicking::rust_panic_with_hook
             at ru
st/toolchains/nightly-2022-11-15-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:692:13
   2: std::panicking::begin_panic_handler::{{closure}}
             at rust/toolchains/
nightly-2022-11-15-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:579:13
   3: std::sys_common::backtrace::__rust_end_short_backtrace
             at rust/toolchains/nightly-
2022-11-15-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:137:18
   4: rust_begin_unwind
             at rust/toolchains/nightly-2022-11-15-x86_64-unknown-linux-gn
u/lib/rustlib/src/rust/library/std/src/panicking.rs:575:5
   5: core::panicking::panic_fmt
             at rust/toolchains/nightly-2022-11-15-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/s
rc/panicking.rs:65:14
   6: raftstore::store::fsm::apply::ApplyDelegate<EK>::handle_ingest_sst
             at home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tikv/components/raftsto
re/src/store/fsm/apply.rs:2005:17
      raftstore::store::fsm::apply::ApplyDelegate<EK>::exec_write_cmd
             at home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tikv/component
s/raftstore/src/store/fsm/apply.rs:1755:39
      raftstore::store::fsm::apply::ApplyDelegate<EK>::exec_raft_cmd
             at home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tikv/c
omponents/raftstore/src/store/fsm/apply.rs:1678:13
      raftstore::store::fsm::apply::ApplyDelegate<EK>::apply_raft_cmd
             at home/jenkins/agent/workspace/build-common/go/src/github.com/pingc
ap/tikv/components/raftstore/src/store/fsm/apply.rs:1442:45
   7: raftstore::store::fsm::apply::ApplyDelegate<EK>::process_raft_cmd
             at home/jenkins/agent/workspace/build-common/go/src/githu
b.com/pingcap/tikv/components/raftstore/src/store/fsm/apply.rs:1378:52
   8: raftstore::store::fsm::apply::ApplyDelegate<EK>::handle_raft_entry_normal
             at home/jenkins/agent/workspace/build-
common/go/src/github.com/pingcap/tikv/components/raftstore/src/store/fsm/apply.rs:1256:24
      raftstore::store::fsm::apply::ApplyDelegate<EK>::handle_raft_committed_entries
             at home/jenkin
s/agent/workspace/build-common/go/src/github.com/pingcap/tikv/components/raftstore/src/store/fsm/apply.rs:1130:43
   9: raftstore::store::fsm::apply::ApplyFsm<EK>::resume_pending
             at home/je
nkins/agent/workspace/build-common/go/src/github.com/pingcap/tikv/components/raftstore/src/store/fsm/apply.rs:4107:13
      <raftstore::store::fsm::apply::ApplyPoller<EK> as batch_system::batch::PollHand
ler<raftstore::store::fsm::apply::ApplyFsm<EK>,raftstore::store::fsm::apply::ControlFsm>>::handle_normal
             at home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tikv/component
s/raftstore/src/store/fsm/apply.rs:4588:13
  10: batch_system::batch::Poller<N,C,Handler>::poll
             at home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tikv/components/batch-
system/src/batch.rs:422:27
  11: raftstore::store::worker::refresh_config::PoolController<N,C,H>::increase_by::{{closure}}
             at home/jenkins/agent/workspace/build-common/go/src/github.com/pin
gcap/tikv/components/raftstore/src/store/worker/refresh_config.rs:83:21
      <std::thread::Builder as tikv_util::sys::thread::StdThreadBuildWrapper>::spawn_wrapper::{{closure}}
             at home/jen
kins/agent/workspace/build-common/go/src/github.com/pingcap/tikv/components/tikv_util/src/sys/thread.rs:427:23
      std::sys_common::backtrace::__rust_begin_short_backtrace
             at rust/toolcha
ins/nightly-2022-11-15-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:121:18
  12: std::thread::Builder::spawn_unchecked_::{{closure}}::{{closure}}
             at
 rust/toolchains/nightly-2022-11-15-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/mod.rs:551:17
       <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<
()>>::call_once
             at rust/toolchains/nightly-2022-11-15-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/panic/unwind_safe.rs:271:9
      std::panicking::try::do_call

    at rust/toolchains/nightly-2022-11-15-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:483:40
          std::panicking::try
                 at rust/toolchains/nightly-2022-11-15-x
86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:447:19
      std::panic::catch_unwind
             at rust/toolchains/nightly-2022-11-15-x86_64-unknown-linux-gnu/lib/rustlib/sr
c/rust/library/std/src/panic.rs:137:14
      std::thread::Builder::spawn_unchecked_::{{closure}}
             at rust/toolchains/nightly-2022-11-15-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/
std/src/thread/mod.rs:550:30
      core::ops::function::FnOnce::call_once{{vtable.shim}}
             at rust/toolchains/nightly-2022-11-15-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src
/ops/function.rs:513:5
  13: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at rust/toolchains/nightly-2022-11-15-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/lib
rary/alloc/src/boxed.rs:2000:9
      <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at rust/toolchains/nightly-2022-11-15-x86_64-unknown-linux-gnu/lib/rustlib/src/
rust/library/alloc/src/boxed.rs:2000:9
      std::sys::unix::thread::Thread::new::thread_start
             at rust/toolchains/nightly-2022-11-15-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/st
d/src/sys/unix/thread.rs:108:17
  14: start_thread
  15: clone3
"] [location=/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tikv/components/raftstore/src/store/fsm/apply.rs:2005]
[thread_name=apply-low-0]

import logic is independent with raft, so it's hard to tell whether an intermediate import SST file will be used in future. Because of this, we don't have a simple logic to clean up stale import SST file.
Take this as an example: clean up thread found there's a import SST file whose region is not at this TiKV (so can't use region epoch to check staleness), but it can't know

whether the region has been removed from this TiKV, or
whether the region will be scheduled to this TiKV in following raft log, or
whether the region will be scheduled to this TiKV in following raft log, and it will be removed afterwards. https://github.com/tikv/tikv/issues/10438#issuecomment-897481656

in order to solve this problem, we plan to add a synchronize point to the import client (lightning). The import client has a write+ingest protocal like 2 phase commit. When the server receives a "write" request, it should return "retry later" error to the client when the region is not ready. So for a successful "write" request, server can guarantee the following "ingest" request must success as long as the region is still on this TiKV. And when the region is gone "ingest" request must fail because region confver is changed.

import logic is independent with raft, so it's hard to tell whether an intermediate import SST file will be used in future. Because of this, we don't have a simple logic to clean up stale import SST file.
Take this as an example: clean up thread found there's a import SST file whose region is not at this TiKV (so can't use region epoch to check staleness), but it can't know

whether the region has been removed from this TiKV, or
whether the region will be scheduled to this TiKV in following raft log, or
whether the region will be scheduled to this TiKV in following raft log, and it will be removed afterwards. TiKV panic because of ingest files not exist. #10438 (comment)

in order to solve this problem, we plan to add a synchronize point to the import client (lightning). The import client has a write+ingest protocal like 2 phase commit. When the server receives a "write" request, it should return "retry later" error to the client when the region is not ready. So for a successful "write" request, server can guarantee the following "ingest" request must success as long as the region is still on this TiKV. And when the region is gone "ingest" request must fail because region confver is changed.

can you help check this idea? @Leavrth @Connor1996 @YuJuncen

Could you elaborate on what is causing "region is not ready"?
AFAIK, if a ingest is committed, it will either be applied successfully or it doesn't get applied*, it never fails.
* Apply may be slow and a region is remove by a new region before applying ingest. And the new region must contain ingested data.

The panic is more like a bug in cleanup sst task.

what is causing "region is not ready"?

https://github.com/tikv/tikv/issues/10438#issuecomment-897481656

if a ingest is committed, it will either be applied successfully or it doesn't get applied*, it never fails.

for "ingest request must fail" I mean fail to commit.

The panic is more like a bug in cleanup sst task.

Yes, and I want to simplify the import logic to fix the cleanup logic. With the changes at import side, cleanup will either left stale SST files or remove them too early when import_mode is off.

what is causing "region is not ready"?

#10438 (comment)

I see. How about let  tikv check region epoch for write RPC? If there is no such region or epoch mismatch just fails the RPC and let lightning retry.

if a ingest is committed, it will either be applied successfully or it doesn't get applied*, it never fails.

for "ingest request must fail" I mean fail to commit as in handle_ingest_sst

Currently, handle_ingest_sst never fails unless sst files are removed unexpectedly.

How about let tikv check region epoch for write RPC? If there is no such region or epoch mismatch just fails the RPC and let lightning retry.

I'm doing this. Currently I have added RegionInfoAccessor as a member of ImportSstService, so in write RPC it can check region epoch. But I see RegionInfoAccessor only has a few usage, not sure if this is the recommended way to check region epoch.

Currently, handle_ingest_sst never fails unless sst files are removed unexpectedly.

The region_id, epoch and conf_ver is encoded in SST filename, and handle_ingest_sst should be able to check them in check_sst_for_ingestion
https://github.com/tikv/tikv/blob/bd11fb033e85512f0dd20cffaf1bcefc5e8c0bd6/components/raftstore/src/store/fsm/apply.rs#L1975-L1984

some timeline info:
tidb-2, cancel and exit import mode at 10:51, but until 11:46 the framework start cancelling subtask, due to tikv flow control, updating system table is slow.
[2023/06/25 10:51:07.775 +00:00] [INFO] [dispatcher.go:304] ["process flow, handle an error"] [task-id=1] ["err msg"="[cancel]"]
[2023/06/25 10:51:07.775 +00:00] [INFO] [dispatcher.go:280] ["process error flow"] [type=ImportInto] [task-id=1] [step=import] [error-message="[cancel]"]
[2023/06/25 10:51:07.776 +00:00] [INFO] [tikv_mode.go:59] ["switch tikv mode"] [type=ImportInto] [task-id=1] [step=import] [mode=Normal]
...
[2023/06/25 10:51:08.212 +00:00] [INFO] [dispatcher.go:429] ["execute sql"] [type=ImportInto] [task-id=1] [step=import] [sql="TRUNCATE `big`.`items`"] [args=null]
...
[2023/06/25 10:51:08.462 +00:00] [INFO] [ddl.go:1067] ["[ddl] start DDL job"] [job="ID:105, Type:truncate table, State:queueing, SchemaState:none, SchemaID:100, TableID:102, RowCount:0, ArgLen:3, start ti
me: 2023-06-25 10:51:08.285 +0000 UTC, Err:<nil>, ErrCount:0, SnapshotVersion:0"] [query="TRUNCATE `big`.`items`"]
[2023/06/25 10:56:02.072 +00:00] [INFO] [ddl.go:1169] ["[ddl] DDL job is finished"] [jobID=105]
...
[2023/06/25 11:46:00.143 +00:00] [WARN] [session.go:1287] [sql] [label=internal] [error="[kv:8022]Error: KV error safe to retry Error(Txn(Error(Mvcc(Error(TxnLockNotFound { start_ts: TimeStamp(442418566315376641), commit_ts: TimeStamp(442418650083753992), key: [116, 128, 0, 0, 0, 0, 0, 0, 84, 95, 105, 128, 0, 0, 0, 0, 0, 0, 1, 1, 99, 97, 110, 99, 101, 108, 108, 105, 255, 110, 103, 0, 0, 0, 0, 0, 0, 249, 3, 128, 0, 0, 0, 0, 0, 0, 1] }))))) {tableID=84, indexID=1, indexValues={cancelling, 1, }} [try again later]"] [txn="Txn{state=invalid}"]
[2023/06/25 11:46:08.652 +00:00] [INFO] [manager.go:221] [onCanceledTasks] [dist_task_manager=upstream-tidb-2.upstream-tidb-peer.import-into-20t-tps-1811937-1-810.svc:4000] [id=1]

tidb-0
[2023/06/25 11:46:08.459 +00:00] [INFO] [manager.go:221] [onCanceledTasks] [dist_task_manager=upstream-tidb-0.upstream-tidb-peer.import-into-20t-tps-1811937-1-810.svc:4000] [id=1]

tikv-2, panic at 11:09
[2023/06/25 11:09:56.086 +00:00] [FATAL] [lib.rs:497] EngineTraits(Engine(Status { code: IoError, sub_code: None, sev: NoError, state: \"IO error: No such file or directory: while stat a file for size:
/var/lib/tikv/data/import/ff428250-5830-4978-849c-e1f1127b3693_15563516_47_734_write.sst: No such file or directory
handle_ingest_sst

Currently, handle_ingest_sst never fails unless sst files are removed unexpectedly.

@overvenus @lance6716 The statement above seems not true. It will check epoch inside check_sst_for_ingestion which is called by handle_ingest_sst.
It's ok to use RegionInfoAccessor for checking epoch, it's not strictly up-to-date, but it's good enough.
In case of the stale information, then handle_ingest_sst will still fail the ingestion.

1 whether the region has been removed from this TiKV, or
2 whether the region will be scheduled to this TiKV in following raft log, or
3 whether the region will be scheduled to this TiKV in following raft log, and it will be removed afterwards.
https://github.com/tikv/tikv/issues/10438#issuecomment-897481656

@lance6716 So do you mean when the SST file is uploaded, in today's code, we don't check if the SST's region is on this TiKV?  If we check it, then 2 or 3 will not happen.  We can only need to deal with 1. And just delete the SST file in cleanup thread if the region cannot be found or epoch is stale.

Is it concluded that why sst files are cleaned up here ?
I don't find the exact reason in the discussion.

@mittalrishabh It's about the SST cleaning mechanism. Today a SST can be deleted after it's successfully applied. The problem is that when the SST has not been applied, today we don't have a reliable way to tell if the SST is going to be applied or not-----because today when uploading SST, TiKV does not check if the SST's region is in that tikv or if the epoch of SST matches the region's epoch. This is because in lightning scenario,  lightning client could upload SST to a TiKV first and then schedule the related regions to that TiKV.
And therefore, we introduce a flag called import mode.  When import mode is on, then these SSTs are not deleted even if TiKV does not have their regions.
This bug happens when an import job cancels,  the import mode in TiKV exits and thus TiKV cleaning task deletes these SSTs. However, the import job may not stop at same time as the import mode exits in TikV side. And therefore an SST could be mistakenly deleted by TiKV and thus leads to this issue.
The fix we're going to do is to make sure SST upload will have to be done after that region is in the TiKV.  And also may optimize the import job cancelation to avoid disparity of timing between import job and tikv import mode.

/affects release-7.5

I don't understand few things here

TiKV does not check if the SST's region is in that tikv
How is that possible. Region is scheduled to that tikv before lightning start sending SST files. And if region moves than ingest RPC should fails because there is no leader.


Improve test setup in the core module

Move all under-test compilation logic into FixtureCompiler
Extend setup to enable dynamic fixture creation, which allows using SQL strings as test inputs

this is on working-kotlin, so it's missing the same cases as before. This will provide the tools for moving tests against the gradle plugin into tests against the core which should be a lot less hectic
Moving away from parameterized because it doesn't work well with targeting a single fixture. Doesn't work well as in I can't remember the last time I was able to get AS to run a single test in a parameterized test, but I think it worked at some point.
I think most tests will end up being the string input style, its really only for happy-path codegen that using an actual source file is going to be a lot cleaner/easier to maintain

Ah, mobile doesn't show the target branch. :+1:
On Sat, Oct 21, 2017, 10:05 AM Alec Strong<EMAIL_ADDRESS>wrote:

this is on working-kotlin, so it's missing the same cases as before. This
will provide the tools for moving tests against the gradle plugin into
tests against the core which should be a lot less hectic
Moving away from parameterized because it doesn't work well with targeting
a single fixture. Doesn't work well as in I can't remember the last time I
was able to get AS to run a single test in a parameterized test, but I
think it worked at some point.
I think most tests will end up being the string input style, its really
only for happy-path codegen that using an actual source file is going to be
a lot cleaner/easier to maintain
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/square/sqldelight/pull/680#issuecomment-338401240,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEEEbK0ax_oz16JnW2wt0ne65whRoCOks5sufoygaJpZM4QBkpa
.

Also wrt parameterized test there isnt a good way to mark them as dirty. I think the extra code to have explicit tests is reasonable for the gain of keeping things simple and working without having to run a clean build from command line
If all those problems are solvable im totally cool going back to parameterized tests.

The problem with requiring a test function and naming the folder is that
you inevitably forget to make the function and only add the folder and now
you have cases which aren't running. So I'd prefer we move as much as
possible to string-based so avoid this problem.
On Sat, Oct 21, 2017, 10:07 AM Alec Strong<EMAIL_ADDRESS>wrote:

Also wrt parameterized test there isnt a good way to mark them as dirty. I
think the extra code to have explicit tests is reasonable for the gain of
keeping things simple and working without having to run a clean build from
command line
If all those problems are solvable im totally cool going back to
parameterized tests.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/square/sqldelight/pull/680#issuecomment-338401583,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEEEY2vv8Exjp5Fc6QT2zSwLs01dJHQks5sufq6gaJpZM4QBkpa
.

Setup should allow painless switching between parameterized/string-based/file-based test cases, as different styles fit different test cases better. E.g. I'd prefer string-based for error cases (more granular) and fixture-based for happy paths (complete use-cases).

Maybe we eliminate all fixture tests and do only integration tests for
positive cases? As long as the behavior and API are correct I don't much
care about the generated code.
On Sat, Oct 21, 2017, 10:11 AM Egor Andreevici<EMAIL_ADDRESS>wrote:

Setup should allow painless switching between
parameterized/string-based/file-based test cases, as different styles fit
different test cases better. E.g. I'd prefer string-based for error cases
(more granular) and fixture-based for happy paths (complete use-cases).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/square/sqldelight/pull/680#issuecomment-338402184,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEEEfv1kZOBDtTTobpDKWmAXYQUW_-uks5suft5gaJpZM4QBkpa
.

Was just about to comment that. +1
I think its probably worth having like a single "expected" code gen test checked in so its easier to review changes to the generated code
but then we can move away from fixtures entirely, except for a few to verify integration/gradle plugin work fine

Right, that would be a good split into unit/integration tests - have a lot of tests that take strings as inputs, and a few fixture tests.

Sounds good!
On Sat, Oct 21, 2017, 10:17 AM Egor Andreevici<EMAIL_ADDRESS>wrote:

Right, that would be a good split into unit/integration tests - have a lot
of tests that take strings as inputs, and a few fixture tests.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/square/sqldelight/pull/680#issuecomment-338403439,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEEEfawKhrpEXIS_Enb6AJdxAKCauhSks5suf0WgaJpZM4QBkpa
.


Add  --eot_line option

Added --eot_line option.
This allows multi lines input.
For example, we can use the following prompt with --eot_line EOT .
Please follow the instructions.

1. aaa
2. bbb
3. ccc
EOT

There's definitely a need for this. If you notice in the shell demo there's this tr '\n' ' ' step to workaround the the issue.
It does change the function interface slightly and presence/absence of whitespace like "\n" can have subtle effects on quality, so the details require a bit of care.


Missing documentation for everything not Helmholtz

Hello,
I am currently trying to implement a Julia-interface for this library (pretty much a copy-paste of the one for FMM3D). However, the documentation seem to only cover the Helmholtz problem. Is it safe to assume that the Laplace problem is defined similar to the Helmholtz problem, i.e. something like
$$
u(x) = \sum_{j=1}^{N} c_j\log(\|\mathbf{x} -\mathbf{x}_j\|) - v_j\mathbf{d}_j\cdot\nabla \log(\|\mathbf{x} -\mathbf{x}_j\|) \quad ?
$$
Furthermore there is also implemented other kernels, but I have no experience working with these. As such I have no idea how their potential might look like and hence have problems implementing a possible interface.
Cheers,
Mikkel

Hi Manas,
Most of the work were already done by Travis for the 3D version, so most of the credit should go to him 😄
Don't stress too much about getting the documentation in place. I personally only need the Helmholtz interface, but I thought I might as well implement the others while I was at it.
Cheers,
Mikkel

Any update on this?

Dear Mikel,
Apologies for the delay in this. We've been dealing with some feature upgrades. We hope to have the library up to date on documentation within the month.

Sounds good. I was just asking since somebody mentioned in the registration of the Julia wrapper of FMM3D that the Julia wrapper of FMM2D only contained Helmholtz (the reason here being the lack of documentation).
Anyhow, please let me know when the upgrade is released so that I can upgrade the Julia wrapper. Are some of the feature upgrades important? (In this case I would have to upgrade the binaries)
In addition, if you prefer to have the Julia wrapper directly in this repository (similar to how it is for FMM3D), then I would be happy to transfer it.

Someone just asked for Laplace and Stokes in the 2D wrapper. Is there any update on the documentation? If there it is soon there, I will wait until then. Otherwise I guess I will have to look a bit into the source-code 🧑💻

Hi Mikel, sorry about the delay. I'm in the process of getting those sets of documentation in. I should probably have them by the end of next week. Would an updated math.rst suffice for now?

Dear Mikkel,
I have updated the documentation on the math side that lays down all the definitions. I'll add in the documentation for the fortran, python and matlab wrappers soon.
You can find the math documentation at https://fmm2d.readthedocs.io/en/latest/math.html

Hi Manas,
Thanks a lot! Having the math will help a lot!

A short update: I am having a bit of trouble with the cfmm2d functionality. In the documentation it is stated as $\text{log}(|z - \varepsilon_j|)$, but I keep getting imaginary potentials out for charges with 0-imaginary part and no dipoles. My only idea is that it might be $\text{log}(z - e_j)$, but I still do not get the correct value out for my dense test calculation.
Note that the binary currently wrapped is about two years old, so it might also be due to that?

Yes, that is in fact an artifact from a previous commit. We realized this issue and changed the behavior of cfmm2d to fix this.

Ahh ok. I guess I will have to figure out how to update the binaries. Is there some updates coming soon or would it be a good idea to already update the binaries now?

I think it might be worthwhile updating the binaries now. We are hoping to add elasticity FMMs in the near future and maybe even update integers to 8 byte integers to be consistent with our other libraries, but both of those things could take a month+

Perfect, I will try to update the binaries.
The way Julia updates them, however, requires a version number. I can see that the documentation still say 1.0.0, which is what the current binaries are called. I might be able to override them, but it would be easier if I could just bump the version to e.g. 1.0.1 or 1.1.0?

Let's call it version 1.1.0, I've updated that in the docs and will update a release too once I get all the matlab and python wrappers + documentation in place

Sounds good!


how to use with scalelite?

How to use bbb-mp4 with scalelite?

Hi @mohammad362

Install bbb-mp4 on each bbb-server
Make sure all bbb-mp4  will keep mp4 at one common place ( You can use nfs mounting ). change COPY_TO_LOCATION in .env
for example COPY_TO_LOCATION=/mnt/scalelite-recordings/var/bigbluebutton/mp4
Copy index.html and download-button.js  from any bbb server where you have bbb-mp4 installed  to scalelite server
index.html location in bbb server : /var/bigbluebutton/playback/presentation/2.3/index.html
download-button.js location in bbb server  : /var/bigbluebutton/playback/presentation/2.3/download-button.js
Create a file mp4_recording.nginx on scalelite server with below code,

location /mp4 {
    root   /var/www/bigbluebutton-default;
    index  index.html index.htm;
    expires 1m;
}

Mount all those files and mp4 folder to scalelite nginx container
Add below lines  to nginx container's volume section (please change the files locations as per your setup)

        # Mp4 files mounting to  nginx container
        - /mnt/scalelite-recordings/var/bigbluebutton/mp4/:/var/www/bigbluebutton-default/mp4/
        # mp4 playback support
        - ./bbb-mp4/mp4_recording.nginx:/etc/bigbluebutton/nginx/mp4_recording.nginx
        - ./bbb-mp4/playback/index.html:/var/bigbluebutton/playback/presentation/2.3/index.html
        - ./bbb-mp4/playback/download-button.js:/var/bigbluebutton/playback/presentation/2.3/download-button.js

Hi @mohammad362
* Install bbb-mp4 on each bbb-server

* Make sure all bbb-mp4  will keep mp4 at one common place ( You can use nfs mounting ). change COPY_TO_LOCATION in .env
  for example COPY_TO_LOCATION=`/mnt/scalelite-recordings/var/bigbluebutton/mp4`

* Copy index.html and download-button.js  from any bbb server where you have bbb-mp4 installed  to scalelite server
  index.html location in bbb server :` /var/bigbluebutton/playback/presentation/2.3/index.html`
  download-button.js location in bbb server  : `/var/bigbluebutton/playback/presentation/2.3/download-button.js`

* Create a file mp4_recording.nginx on scalelite server with below code,

location /mp4 {
    root   /var/www/bigbluebutton-default;
    index  index.html index.htm;
    expires 1m;
}

* Mount all those files and mp4 folder to scalelite nginx container
  Add below lines  to nginx container's volume section (please change the files locations as per your setup)

        # Mp4 files mounting to  nginx container
        - /mnt/scalelite-recordings/var/bigbluebutton/mp4/:/var/www/bigbluebutton-default/mp4/
        # mp4 playback support
        - ./bbb-mp4/mp4_recording.nginx:/etc/bigbluebutton/nginx/mp4_recording.nginx
        - ./bbb-mp4/playback/index.html:/var/bigbluebutton/playback/presentation/2.3/index.html
        - ./bbb-mp4/playback/download-button.js:/var/bigbluebutton/playback/presentation/2.3/download-button.js

thanks, i test and report


feat!: support oras.TagN

Resolves #287
Fixes #298
BREAKING CHANGE: deprecate registry.ReferenceTagger and Repository.TagReference
Signed-off-by: Sylvia Lei<EMAIL_ADDRESS>

Codecov Report

Merging #301 (67697f2) into main (9a92908) will increase coverage by 0.30%.
The diff coverage is 70.39%.

@@            Coverage Diff             @@
##             main     #301      +/-   ##
==========================================
+ Coverage   71.57%   71.88%   +0.30%
==========================================
  Files          37       37
  Lines        3515     3560      +45
==========================================
+ Hits         2516     2559      +43
  Misses        747      747
- Partials      252      254       +2

Impacted Files
Coverage Δ

internal/registryutil/proxy.go
65.90% <0.00%> (-5.52%)
:arrow_down:

registry/repository.go
0.00% <ø> (ø)

registry/remote/repository.go
66.21% <67.53%> (+0.48%)
:arrow_up:

content.go
79.06% <76.38%> (+2.78%)
:arrow_up:

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


bug: robots API issue for the TWAP bot

robots API is sending the bought token info for the coin_info and coin_info1 on the TWAP bot.
I created a TWAP bot with ETH and USDT but API is returning only USDT info at the coin_info and coin_info1.

this is actually coin_info0


ble plugin not working in galaxy s6

I use megster version 0.1.2 as a ble plugin for phone gap application to connect to ble devices.Using this plugin I can connect to device in galaxy S5 having android version 4.4.2 but I am getting problem in Galaxy S6 having version 5.1.1.
I use same pluging in different android versions it works fine their who supports BLE.
Is there any problem related to S6 and ble plugin

Hi @cajay01,
That version of the BLE plugin is no longer available or supported on npm. We have updated the version used on the dev app<EMAIL_ADDRESS>Maybe using this version will help to solve your problem. Please let me know if this helps.

Thank you Suraj I will try with it

Hey Suraj I tried with new plugin but its not working even on other devices where previous plugin was working correctly

Hey Suraj I tried with new plugin but its not working even on other devices where previous plugin was working correctly

Is there any specific cordova-ionic version supposed to use with this plugin?

As far as I can tell, there are no restrictions on the cordova/ionic version. I will continue to investigate this further.

I have looked more into this, as far as I can tell it doesn't seem to be a problem with the developer app. This may be a problem with the BLE plugin. I am going to close this issue. @cajay01


[react-fela] Fix useFela hook types to support composition

Description
#845
Packages
List all packages that have been changed.

react-fela

Versioning
Patch
Checklist
Quality Assurance

You can also run yarn run check to run all 4 commands at once.

[x] The code was formatted using Prettier (yarn run format)
[x] The code has no linting errors (yarn run lint)
[x] All tests are passing (yarn run test)
[x] There are no flow-type errors (yarn run flow)

Changes
If one of the following checks doesn't make sense due to the type of PR, just check them.

[x] Tests have been added/updated
[x] Documentation has been added/updated
[x] My changes have proper flow-types

Amazing, thank you :)

Amazing, thank you :)


Missing toStr() method on integer implementation

https://developer.roku.com/docs/references/brightscript/interfaces/ifintops.md

This was already implemented in v0.16.0 closing


resolving service alias with periods (DNS)

refactored from #7970.
We have a service alias, and link to it from another service using an alias for a fqdn. In 1.1.4 the aliased link resolves to the address of the service alias, where as in 1.4.1 it returns the address found on external DNS for the fqdn.
  nginx:
    image: xxx:nnn/nginx/master:latest
    external_links:
    - global/api:api.www.7943.xxx.se
    volumes_from:
    - dddd
    labels:
      io.rancher.sidekicks: dddd
      io.rancher.container.hostname_override: container_name

in the nginx service, api.www.7943.xxx.se does not resolve to the address of global/api, as it does in 1.1.4.
The rancher dns service has records like this, both on our 1.1.4 and 1.4.1 systems, for the nginx service:
  "<IP_ADDRESS>": {
    "search": [
      "7921-dddd.rancher.internal",
      "zzz.7921-dddd.rancher.internal",
      "rancher.internal"
    ],
    "recurse": [],
    "authorative": [],
    "a": {
      "api.www.7921.dddd.mr.xxxxx.se.global.rancher.internal.": {
        "answer": [
          "<IP_ADDRESS>"
        ]
      },
      "api.www.7921.trinidad.mr.ocean.svenskaspel.se.rancher.internal.": {
        "answer": [
          "<IP_ADDRESS>"
        ]
      },
      "qqqq.7921-dddd.rancher.internal.": {
        "answer": [
          "<IP_ADDRESS>"
        ]
      },
      "qqqq.rancher.internal.": {
        "answer": [
          "<IP_ADDRESS>"
        ]
      }
    },
    "cname": {}
  },

When looking up api.www.7921.dddd.mr.xxxxx.se on 1.1.4 we get the data from answers.json but on 1.4.1 we get the data from our dns servers.

Close in favor of https://github.com/rancher/rancher/issues/7717


Search for articles that don't match the pattern

Inverted search feature would be good.
/<searchstring>  looks for search string. But I want to have matches, where the search string is not found.

Maybe <searchstring> for inverted search?

Wouldn't a filter suffice?

Just thought about filter... not used that so far. Maybe it makes sense.

Just tried a filter-expression and newaboat does not react on any keyboard commands any more...

If you want any advice or help with this, please provide details, for example:

what did you do, step-by-step, beginning with starting Newsboat?
how many items did you expect to see (preferably with some reasoning, like "I only have 10 feeds with 200 items in each")?
is Newsboat busy (top/iotop are your friends here), or did it simply hang (might be a good idea to attach with GDB and look at the backtrace)?


Feature suggestion - cursor position

ANSI escape codes can be used to change cursor position.
This program here does that - https://github.com/fidian/ansi
But it's yours that's in the Nix repositories and I'd find it easier to rely on that, particularly for some scripts I'd like to distribute to other Nix users.
It seems your program only focuses on color at this time but it could do much more with ANSI escape codes.

Hey, great idea! Unfortunately, I do not have capacity for that now or in the near future.
Feel free to submit a PR

Totally understood.


Accel World vs. Sword Art Online [PCSE01071]

App summary

App name: Accel World vs. Sword Art Online [
App serial: PCSE01071
App version: 1.0

Vita3K summary

Version: v0.1.5
Build number: 2786-7ac13c3c
Commit hash: https://github.com/Vita3K/Vita3K/commit/7ac13c3c3ce219a7548a815a1641e45863da50f3
CPU backend:Dynarmic

Test environment summary

Tested by: benderscruffy
OS: Windows 10
CPU: Intel Core i7 920
GPU: AMD RX 580
RAM: 16 GB

Issues
goes ingame and is playable
the problems so far is during the first fights there is a lot of the game pausing of the characters as you run to fight other baddies
and during the first fight the graphics start to glitch
Screenshots

Log
vita3k.zip
Recommended labels

ingame+

RETESTED - I would like to report a regression - this game crashes after pressing start and watching the intro movie on Vulkan. It will play and not crash on OpenGL but it is far too slow to play.
Logs show: Unhandled C++ exception. vk::Queue::submit:
Vita3K summary

Version: v0.1.8
Build number: 3160
Commit hash: https://github.com/vita3k/vita3k/commit/[1c009661]
CPU backend: Dynarmic
GPU backend: Vulkan

Test environment summary

Tested by: JackMonty
OS: Windows 10
CPU: AMD Ryzen 5 Pro 3500U
GPU: Nvidia Geforce GT1030
RAM: 32 GB

Log
vita3k.log
Recommended labels

Intro
Crash

Tried it out on android, it's completely playable other than the DLC "castaway from another world" not working and few graphical with bosses, it's completely playable.

App summary

App name: Accel World vs. Sword Art Online
App serial: PCSE01071
App version: 1.00

Vita3K summary

Version: v0.2.0
Build number: 3691
Commit hash: https://github.com/vita3k/vita3k/commit/31826697
CPU backend: Dynarmic
GPU backend: Vulkan

Test environment summary

Tested by: Benjamin Toledo
OS: Windows 11
CPU: AMD Ryzen 5 4600G
GPU: AMD Radeon(TM) Graphics

Issues

No issues

Screenshot

Log
vita3k.log
Recommended labels

Playable


can't build version 3.24.0

Hi !
The current build is failing because the last version of the standalone C
sqlite3 library from Wx-sqlite3 require gcc5. I have to update docker
images used during the build process.
Le ven. 27 juil. 2018 à 11:39, ssqgrand<EMAIL_ADDRESS>a écrit :

Closed #5 https://github.com/Willena/sqlite-jdbc-crypt/issues/5.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Willena/sqlite-jdbc-crypt/issues/5#event-1756889438,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABtA0RCK_HtqYOJb4WdT75qqFaZSv0Vfks5uKt_ugaJpZM4VjMQO
.


sctp_os_macosx.h missing?

netinet/sctp_os.h references netinet/sctp_os_macosx.h, but that file doesn't exist.  I don't know how this built before on mac os!

This file is only needed when you build the network kernel extension, not the userland stack. You should be able to compile the userland stack on Mac OS X by just running
./bootstrap
./configure
make
At I can...

This is for a separate build procedure.  Is sctp_os.h also not supposed to be needed when building in-kernel?

sctp_os.h is used when building a kernel stack or a userland stack. You can use  a different build environment, but make sure you use the same -D and -U parameters as provided in the example build environment. Have a look at
https://github.com/sctplab/usrsctp/blob/master/configure.ac#L39
and
https://github.com/sctplab/usrsctp/blob/master/configure.ac#L43
for building on Mac OS X.

Ah, great, thank you!


couple of bug fixes for controller.

Now, the controller can reconcile basic IstioControlPlane object and apply istio manifests in cluster.

@morvencao: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gencheck_operator
87811552d1eef25689a3411811af9bfe4aa1cc14
link
/test gencheck_operator

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@morvencao: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gencheck_operator
45558298eb5016ddcc184e19135368164ebccc9f
link
/test gencheck_operator

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Tried GetMoarFediverse with Akkoma - pgsql exception

Hi @g3rv4,
Been giving your GetMoarFediverse app a try as I love the concept and was wondering if it could work with my Akkoma instance (fork of Pleroma) and it appears that it has run into a snag, not sure if it just plainly doesn't support downloading all the hashtags from Akkoma's pgsql db or what not.
When running the importdata, it returned the following error:
Unhandled exception. Npgsql.PostgresException (0x80004005): 42P01: relation "tag_follows" does not exist

POSITION: 32
   at Npgsql.Internal.NpgsqlConnector.<ReadMessage>g__ReadMessageLong|225_0(NpgsqlConnector connector, Boolean async, DataRowLoadingMode dataRowLoadingMode, Boolean readingNotifications, Boolean isReadingPrependedMessage)
   at Npgsql.NpgsqlDataReader.NextResult(Boolean async, Boolean isConsuming, CancellationToken cancellationToken)
   at Npgsql.NpgsqlDataReader.NextResult(Boolean async, Boolean isConsuming, CancellationToken cancellationToken)
   at Npgsql.NpgsqlCommand.ExecuteReader(CommandBehavior behavior, Boolean async, CancellationToken cancellationToken)
   at Npgsql.NpgsqlCommand.ExecuteReader(CommandBehavior behavior, Boolean async, CancellationToken cancellationToken)
   at GetMoarFediverse.MastodonConnectionHelper.GetFollowedTagsAsync() in /src/MastodonConnectionHelper.cs:line 21
   at GetMoarFediverse.MastodonConnectionHelper.GetFollowedTagsAsync() in /src/MastodonConnectionHelper.cs:line 25
   at GetMoarFediverse.MastodonConnectionHelper.GetFollowedTagsAsync() in /src/MastodonConnectionHelper.cs:line 10
   at Program.<Main>$(String[] args) in /src/Program.cs:line 52
   at Program.<Main>(String[] args)
  Exception data:
    Severity: ERROR
    SqlState: 42P01
    MessageText: relation "tag_follows" does not exist
    Position: 32
    File: parse_relation.c
    Line: 1392
    Routine: parserOpenTable

May you please advise?
Thanks!

Hi there!
The idea is to pull only the hashtags that are followed by users (not all the tags). I'm not sure if Akkoma supports that, but it seems like the underlying implementation is different (not surprising though).
I haven't tested anything outside of Mastodon. If you find issues and want to open PRs, they're welcome :)


4.6 As an authenticated user, I want to create a request

As an authenticated user, I want to create a request.
Acceptance Criteria:

The map has to have a button to create a request.

Once clicked that button, the user is redirected to the flow and the pages for creating a new request.

ZenHub Information
This information is updated automatically. To modify it, please use ZenHub.
Belonging to Epics:

[EPIC] #904 - Landing Page

@Sangat21 expressed interest in working on this!


typo

Challenge http://beta.freecodecamp.com/challenges/waypoint-ditch-custom-css-for-bootstrap has an issue.

says: "You"
should be: "Your"

Fixed, generated a pull request

closed via #1485