Automated of project structure updation using GitHub workflows and Python scripts

Issue Resolved:

Closes #193

Description
I have added the Project Repository in a new file named PROJECT_STRUCTURE.md :

I have automated the updation of the Project Structure using GitHub workflows and Python scripts. The Project Structure will update when you push any changes to the main branch
I have also added a redirect to the file in the README.md file:

gh_token = os.getenv('GH_TOKEN')
gh_repo = os.getenv('GITHUB_REPOSITORY')

Do I have to create any personal access tokens?
I can see it in your code
also whats the difference between repo_structure and project_structure

gh_token = os.getenv('GH_TOKEN')
gh_repo = os.getenv('GITHUB_REPOSITORY')

Do I have to create any personal access tokens? I can see it in your code
also whats the difference between repo_structure and project_structure

You don't have to make any personalized tokens.
Also repo_structure is a text file where I have used python file handling to create the repository structure first and then the project_structure.md file is to add the headings and other stuff(HTML markdown structure) to make it look good and accessible.

@vansh-codes Check the commit history, I have already tested it once and I have not changed any tokens. It will work as long as the Github Actions bot has write permissions which I have provided:
permissions:
      contents: write   # Permission to the GitHub Bot to access and update the Project Repository

This was creating an issue previously and I debugged it.

why is repo_structure is needed?

why is repo_structure is needed?

repo_structure is a .txt(text) file and the python code was not working earlier on the .md(Markdown) file.

@vansh-codes Have I answered your query?

Okay got it @rajdeepchakraborty-rc

Rewarded level3 for your good work, documentation and such things has to be level2 but you did a goodjob thats why i am giving you level3 on this

Gityzer
Please create same issue for this project also

Gityzer
Please create same issue for this project also

@vansh-codes I will do it by tomorrow and let you know. It is late night for me today and I am signing off for today.

Rewarded level3 for your good work, documentation and such things has to be level2 but you did a goodjob thats why i am giving you level3 on this

Thanks for the appreciation. I am glad that this feature is helpful to people.

@vansh-codes I have opened the issue at:
https://github.com/vansh-codes/Gityzer/issues/71
You can assign it to me. I will complete the work by tomorrow.


Databricks

According to https://learn.microsoft.com/en-us/azure/databricks/administration-guide/cloud-configurations/azure/private-link the Azure Databricks service supports Private Link.
Is there a reason it's omitted from this page?

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

ID: 97849a4b-e79a-840e-8cfc-d43b0ea1dec3
Version Independent ID: 6d224a2c-5e53-832a-ecd4-ae30fd472b76
Content: Azure Private Link availability
Content Source: articles/private-link/availability.md
Service: private-link
GitHub Login: @asudbring
Microsoft Alias: allensu

@VitalyMCT
Thanks for your feedback! We will investigate and update as appropriate.

Thanks for the confirmation. We will await the document update as the next step.

@VitalyMCT
Thanks for your update. We will inform the PG Team to review this and update it as appropriate.
We are going to close this thread. if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.

@RamanathanChinnappan-MSFT I am a bit confused by your latest reply and the sudden closing of this ticket.
Is the support for Private Link there in Databricks and PG is going to simply update the document?
Or is this something you are still checking with PG and there may be a bigger issue here than just out-of-date documentation (i.e. the feature may not be fully supported)?
Either way, let's keep the ticket open until the issue is resolved.


Fix C examples build

Add uthash as submodule
Fix build error (MacOS clang, gcc)

I don't think uthash is a hard dependency for the quiche library itself. Would a documentation update for building C examples be enough?

Right. Also C examples requires libev... so there is more missing dependencies but it's not critical to build Rust main sources. Probably good to document how to build C sources in a separate doc.

AFAIK quiche depends on BoringSSL, not OpenSSL. Unless the examples do something special.

AFAIK quiche depends on BoringSSL, not OpenSSL. Unless the examples do something special.

That's because there was -lcrypto -lssl in Makefile but actually it's not needed. I updated Makefile and readme. I believe libquiche embeds boringssl so no need to link with it externally.

Merged as fe41660096d1747c0290c882d70231183ff2be60, thanks! I squashed the commits together and tweaked the README wording slightly.


Plotting fails to start when plotting to an NTFS Mountpoint via SMB share.

Plotting fails to start when plotting to an NTFS Mountpoint via SMB share.
Remote Windows box:
MP            (NTFS Mount point and SMB share)

Subdir    (Subdirectory of MP )
MP2       (Subdirectory and also a NTFS Mountpoint)

Plotter:
SMB share to \\x.x.x.x\MP
From both Windows and Linux plotting using the root of the share fails:
ID: c515b361ca2b44977b97dd343930c2cde19c1d672bfbcd3208769298b830e093
Plot size is: 32
Buffer size is: 4508MiB
Using 128 buckets
Using 1 threads of stripe size 65536
Caught plotting error: Could not open /home/haitch/temp2/plot-k32-2020-11-01-08-58-c515b361ca2b44977b97dd343930c2cde19c1d672bfbcd3208769298b830e093.plot.sort.tmp: Permission denied
Traceback (most recent call last):
  File "/home/haitch/chia-blockchain/venv/bin/chia", line 33, in <module>
    sys.exit(load_entry_point('chia-blockchain', 'console_scripts', 'chia')())
  File "/home/haitch/chia-blockchain/src/cmds/chia.py", line 59, in main
    return chia(args, parser)
  File "/home/haitch/chia-blockchain/src/cmds/chia.py", line 53, in chia
    return args.function(args, parser)
  File "/home/haitch/chia-blockchain/src/cmds/plots.py", line 146, in handler
    create_plots(args, root_path)
  File "/home/haitch/chia-blockchain/src/plotting/create_plots.py", line 137, in create_plots
    plotter.create_plot_disk(
RuntimeError: std::exception

On both Windows and Linux, plotting to \\x.x.x.x\MP\Subdir does not throw an error.
On Linux, plotting to \\x.x.x.x\MP\MP2 does not throw an error.
On Windows only - plotting to \\x.x.x.x\MP\MP2, plotting again fails.
ID: 0c4af82786302bfe833e138e1e70938d394bdb2a33af13eef3034d99b7639f7f
Plot size is: 33
Buffer size is: 4600MiB
Using 128 buckets
Using 1 threads of stripe size 65536
Caught plotting error: Temp directory z:\chia11 does not exist
Traceback (most recent call last):
  File "src\cmds\chia.py", line 63, in <module>
  File "src\cmds\chia.py", line 59, in main
  File "src\cmds\chia.py", line 53, in chia
  File "src\cmds\plots.py", line 146, in handler
  File "src\plotting\create_plots.py", line 148, in create_plots
RuntimeError: Unknown exception
[6896] Failed to execute script chia

Sent @kiwihaitch a test build

Closing as fixed for the next release


add vCardUrlFilter to fetchVCards

Allow user to override default url filter.
per https://github.com/natelindev/tsdav/commit/2b7766b05356dd37a113d88e331a9b018e8b6c58#r63448931
@natelindev

tests are failing due to external PR cannot access repo secret, merging anyway.


[CAPI] Expose Layer Enums

This patch contains layer enums to be exposed.
Self evaluation:

Build test:	 [X]Passed [ ]Failed [ ]Skipped
Run test:	 [X]Passed [ ]Failed [ ]Skipped

Signed-off-by: jijoong.moon<EMAIL_ADDRESS>

:memo: TAOS-CI Version: 1.5.20200925. Thank you for submitting PR #1863. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://nnstreamer.mooo.com/.

:octocat: cibot: @jijoongmoon, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://nnstreamer.mooo.com/nntrainer/ci/repo-workers/pr-checker/1863-202203251219520.73867511749268-a2c1fcf7ebc7291269734aa3339640cf3b2219f3/.


removed 30 char limit even though it's against standards

opened by mistake - sorry!

No problem. :-)


virsh pool-undefine oooq_pool seems to fail from time to time

fatal: [host0]: FAILED! => {"changed": true, "cmd": ["virsh", "pool-undefine", "oooq_pool"], "d
elta": "0:00:00.029126", "end": "2016-03-15 18:23:19.744160", "failed": true, "invocation": {"m
odule_args": {"_raw_params": "virsh pool-undefine "oooq_pool"", "_uses_shell": false, "chdir"
: null, "creates": null, "executable": null, "removes": null, "warn": true}, "module_name": "co
mmand"}, "rc": 1, "start": "2016-03-15 18:23:19.715034", "stderr": "error: Failed to undefine p
ool oooq_pool\nerror: internal error: no config file for oooq_pool", "stdout": "", "stdout_line
s": [], "warnings": []}
A "rm -rf /run/user/1003/libvirt/" on the host, fixes it

I seem to be hitting this more often than not. Here is a full log of a run that gave the error. I assume something
is not always cleaning up the env fully?
http://acksyn.org/files/tripleo/mrg-08.txt

If you can reliably reproduce this behavior, I would love to take a closer look at your system.  I suspect a libvirt bug, but I haven't been able to reproduce this behavior myself (but somebody else has seen it).

Hey @mbaldessari , we tracked it down: https://www.redhat.com/archives/libvirt-users/2016-March/msg00123.html

Nice @larsks, thanks for tracking it down. I owe you coffee ;)


[BUG] Executing fstrim while rebuilding causes IO errors

Describe the bug (🐛 if you encounter this issue)
Executing fstrim from a priveleged container that mounts a Longhorn volume results in IO errors in the kernel ring buffer if the volume is rebuilding. This would almost certainly also happen if fstrim were executed outside the container.
To Reproduce

Deploy Longhorn on a three node cluster.
Deploy the below manifest, which runs a privileged Ubuntu 22.04 container that mounts a Longhorn volume to /data.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pvc
  namespace: default
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn
  resources:
    requests:
      storage: 10Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  namespace: default
spec:
  restartPolicy: Always
  containers:
  - name: test-container
    image: ubuntu:22.04
    securityContext:
      privileged: true
    args:
      - sleep
      - infinity
    imagePullPolicy: IfNotPresent
    livenessProbe:
      exec:
        command:
          - ls
          - /data/lost+found
      initialDelaySeconds: 5
      periodSeconds: 5
    volumeMounts:
    - name: data
      mountPath: /data
    ports:
    - containerPort: 80
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: test-pvc

Write a reasonably 5GB of data to a file on the volume using dd twice. (Doing it twice may not be necessary, but it results in a bunch of blocks that can be later trimmed.)

eweber@laptop:~/issue-files/SURE-6935> k exec -it test-pod -- bash
root@test-pod:/# dd if=/dev/urandom iflag=count_bytes count=5G bs=1M of=/data/large
5120+0 records in
5120+0 records out
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 47.4062 s, 113 MB/s
root@test-pod:/# dd if=/dev/urandom iflag=count_bytes count=5G bs=1M of=/data/large
5120+0 records in
5120+0 records out
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 58.9104 s, 91.1 MB/s

Verify that the volume's actual size is approximately 10GB as expected.

eweber@laptop:~/longhorn> kl get volume -oyaml pvc-c244bf53-4319-4f77-82cc-e7cf28b31cc9 | grep actual
  actualSize:<PHONE_NUMBER>2

Verify that fstrim executed from the container can clean up approximately 5GB as expected.

root@test-pod:/# fstrim -va
/data: 4.3 GiB<PHONE_NUMBER> bytes) trimmed on /dev/longhorn/pvc-c244bf53-4319-4f77-82cc-e7cf28b31cc9

Write 5GB again to get the volume's actual size back to approximately 10GB.

root@test-pod:/# dd if=/dev/urandom iflag=count_bytes count=5G bs=1M of=/data/large
5120+0 records in
5120+0 records out
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 57.7038 s, 93.0 MB/s
root@test-pod:/# fstrim -va
/data: 0 B (0 bytes) trimmed on /dev/longhorn/pvc-c244bf53-4319-4f77-82cc-e7cf28b31cc9

Verify that the volume's actual size is approximately 10GB.

eweber@laptop:~/longhorn> kl get volume -oyaml pvc-c244bf53-4319-4f77-82cc-e7cf28b31cc9 | grep actual
  actualSize:<PHONE_NUMBER>2

Delete any replica.
Once the replica is rebuilding (snapshots have purged and there is noticeable rebuilding progress), execute fstrim from the container again. No blocks are deleted.

root@test-pod:/# fstrim -va
/data: 0 B (0 bytes) trimmed on /dev/longhorn/pvc-c244bf53-4319-4f77-82cc-e7cf28b31cc9

Check the kernel ring buffer for IO errors. Verify that they occurred during the fstrim operation.

root@test-pod:/# dmesg --ctime | tail -n 200
...
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#83 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#83 Sense Key : Hardware Error [current]
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#83 Add. Sense: Internal target failure
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#83 CDB: Unmap/Read sub-channel 42 00 00 00 00 00 00 00 18 00
[Tue Nov 14 21:46:42 2023] blk_update_request: critical target error, dev sdc, sector 270360 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 0
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#84 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#84 Sense Key : Hardware Error [current]
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#84 Add. Sense: Internal target failure
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#84 CDB: Unmap/Read sub-channel 42 00 00 00 00 00 00 00 18 00
[Tue Nov 14 21:46:42 2023] blk_update_request: critical target error, dev sdc, sector 794648 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 0
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#71 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#71 Sense Key : Hardware Error [current]
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#71 Add. Sense: Internal target failure
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#71 CDB: Unmap/Read sub-channel 42 00 00 00 00 00 00 00 18 00
[Tue Nov 14 21:46:42 2023] blk_update_request: critical target error, dev sdc, sector 1318936 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 0
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#72 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#72 Sense Key : Hardware Error [current]
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#72 Add. Sense: Internal target failure
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#72 CDB: Unmap/Read sub-channel 42 00 00 00 00 00 00 00 18 00
[Tue Nov 14 21:46:42 2023] blk_update_request: critical target error, dev sdc, sector 1843224 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 0
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#73 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#73 Sense Key : Hardware Error [current]
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#73 Add. Sense: Internal target failure
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#73 CDB: Unmap/Read sub-channel 42 00 00 00 00 00 00 00 18 00
[Tue Nov 14 21:46:42 2023] blk_update_request: critical target error, dev sdc, sector 2326528 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 0
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#76 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#76 Sense Key : Hardware Error [current]
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#76 Add. Sense: Internal target failure
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#76 CDB: Unmap/Read sub-channel 42 00 00 00 00 00 00 00 18 00
[Tue Nov 14 21:46:42 2023] blk_update_request: critical target error, dev sdc, sector 2367512 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 0
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#85 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#85 Sense Key : Hardware Error [current]
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#85 Add. Sense: Internal target failure
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#85 CDB: Unmap/Read sub-channel 42 00 00 00 00 00 00 00 18 00
[Tue Nov 14 21:46:42 2023] blk_update_request: critical target error, dev sdc, sector 2621440 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 0
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#86 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#86 Sense Key : Hardware Error [current]
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#86 Add. Sense: Internal target failure
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#86 CDB: Unmap/Read sub-channel 42 00 00 00 00 00 00 00 18 00
[Tue Nov 14 21:46:42 2023] blk_update_request: critical target error, dev sdc, sector 2883584 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 0
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#64 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#64 Sense Key : Hardware Error [current]
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#64 Add. Sense: Internal target failure
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#64 CDB: Unmap/Read sub-channel 42 00 00 00 00 00 00 00 18 00
[Tue Nov 14 21:46:42 2023] blk_update_request: critical target error, dev sdc, sector 3145728 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 0
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#65 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#65 Sense Key : Hardware Error [current]
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#65 Add. Sense: Internal target failure
[Tue Nov 14 21:46:42 2023] sd 3:0:0:1: [sdc] tag#65 CDB: Unmap/Read sub-channel 42 00 00 00 00 00 00 00 18 00
[Tue Nov 14 21:46:42 2023] blk_update_request: critical target error, dev sdc, sector 3407872 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 0

Check the instance-manager logs for associated errors.

eweber@laptop:~/longhorn> kl logs instance-manager-de0a44c527b5c06489d7a009124e4fd3
...
[pvc-c244bf53-4319-4f77-82cc-e7cf28b31cc9-e-0] time="2023-11-14T21:46:42Z" level=info msg="Finished to snapshot: <IP_ADDRESS>:10000 5cea841f-f0b0-44a3-913e-228f38c36c06 UserCreated false Created at 2023-11-14T21:46:42Z, Labels map[]"
time="2023-11-14T21:46:42Z" level=info msg="Adding backend: tcp://<IP_ADDRESS>:10000"
time="2023-11-14T21:46:42Z" level=info msg="Start monitoring tcp://<IP_ADDRESS>:10000"
[longhorn-instance-manager] time="2023-11-14T21:46:42Z" level=info msg="Using replica tcp://<IP_ADDRESS>:10000 as the source for rebuild"
[longhorn-instance-manager] time="2023-11-14T21:46:42Z" level=info msg="Using replica tcp://<IP_ADDRESS>:10000 as the target for rebuild"
[pvc-c244bf53-4319-4f77-82cc-e7cf28b31cc9-e-0] time="2023-11-14T21:46:42Z" level=info msg="Set revision counter of <IP_ADDRESS>:10000 to : 0"
[pvc-c244bf53-4319-4f77-82cc-e7cf28b31cc9-e-0] time="2023-11-14T21:46:42Z" level=info msg="Set backend tcp://<IP_ADDRESS>:10000 revision counter to 0"
[pvc-c244bf53-4319-4f77-82cc-e7cf28b31cc9-e-0] time="2023-11-14T21:46:42Z" level=info msg="Synchronizing volume-head-002.img.meta to volume-head-001.img.meta:<IP_ADDRESS>:10003"
[pvc-c244bf53-4319-4f77-82cc-e7cf28b31cc9-r-418301ed] time="2023-11-14T21:46:42Z" level=info msg="Syncing file volume-head-002.img.meta to <IP_ADDRESS>:10003"
time="2023-11-14T21:46:42Z" level=info msg="Syncing file volume-head-002.img.meta to <IP_ADDRESS>:10003: size 178, directIO false, fastSync false"
[pvc-c244bf53-4319-4f77-82cc-e7cf28b31cc9-r-418301ed] time="2023-11-14T21:46:42Z" level=info msg="Finished sync for the source file volume-head-002.img.meta, size 178, elapsed 0.02s"
[pvc-c244bf53-4319-4f77-82cc-e7cf28b31cc9-r-418301ed] time="2023-11-14T21:46:42Z" level=info msg="Done syncing file volume-head-002.img.meta to <IP_ADDRESS>:10003"
[pvc-c244bf53-4319-4f77-82cc-e7cf28b31cc9-e-0] time="2023-11-14T21:46:42Z" level=info msg="Done synchronizing volume-head-002.img.meta to volume-head-001.img.meta:<IP_ADDRESS>:10003"
response_process: Receive error for response 3 of seq 19169
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:138424320 length:57344
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19170
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:406859776 length:4182016
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19171
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:675295232 length:4182016
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19172
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:943730688 length:4182016
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19173
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:1191182336 length:16777216
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19174
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:1212166144 length:130011136
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19175
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:1342177280 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19176
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:1476395008 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19177
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:1610612736 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19178
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:1744830464 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19179
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:1879048192 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19180
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:2013265920 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19181
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:2281701376 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19182
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:2415919104 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19183
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:2550136832 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19184
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:2684354560 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19185
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:2818572288 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19186
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:2952790016 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19187
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:3087007744 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19188
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:3221225472 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19189
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:3359649792 length:130011136
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19190
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:3489660928 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19191
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:3628085248 length:130011136
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19192
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:3758096384 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19193
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:3892314112 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19194
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:4026531840 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19195
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:4160749568 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19196
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:4496293888 length:67108864
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19197
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:4563402752 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19198
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:4697620480 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19199
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:4831838208 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19200
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:4966055936 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19201
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:5100273664 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19202
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:5234491392 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19203
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:5368709120 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19204
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:5502926848 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19205
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:5637144576 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19206
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:5771362304 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19207
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:5905580032 length:134217728
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success
response_process: Receive error for response 3 of seq 19208
tgtd: bs_longhorn_request(183) Failed to punch hole for UNMAP at offset:6039797760 length:75497472
tgtd: bs_longhorn_request(210) io error 0x1ca3d10 42 0 16 0, Success

Expected behavior
I'm not 100% sure. Maybe there is no way Longhorn can respond differently in this situation? However, Harvester VMs running on top of a Longhorn volume when this occurs pause until the rebuilding finishes (any IO error causes the VM to pause, and every time it unpauses, it experiences the same IO error again), so we need to investigate whether better behavior is possible.
@longhorn/dev-data-plane, is this behavior expected?
Environment

Longhorn version: v1.4.3 and master
Installation method (e.g. Rancher Catalog App/Helm/Kubectl): kubectl
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version: v1.25.12+rke2r1

Number of management node in the cluster: 1
Number of worker node in the cluster: 3

Node config

OS type and version: Ubuntu 22.04.2 LTS
Kernel version: 5.15.0-88-generic
Disk type(e.g. SSD/NVMe/HDD): SSD

Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal): DigitalOcean
Number of Longhorn volumes in the cluster: 1

After digging deeper with the supported customer who originally ran into this issue, we found that their VM had the root filesystem mounted with the discard option (in /etc/fstab). This caused them to hit the issue virtually every time Longhorn replicated. Most users will only hit the issue periodically, as many Linux distributions enable weekly fstrim. For Ubuntu, it generally happens on Mondays in the early morning.

I recall from a previous discussion with @shuo-wu that we return an I/O error when we receive an UNMAP while rebuilding as a precautionary measure. We probably don't need to (since the UNMAP only affects the volume head, which is RW for all replicas during a rebuild). Testing whether this is the case is probably the best path forward for this issue.
However, from reading some discussions online and the SCSI spec, it occurs to me that we can probably legally ignore UNAMP commands if we want to (instead of returning an error). Doing so may limit the effectiveness of our trim support (e.g. a file system may choose not to send an UNMAP again (until reboot) for a particular block if it has already done so), but it would be much better than causing VMs to pause.
Page 28 of Information technology - SCSI Block Commands – 4 (SBC-4)
https://standards.incits.org/apps/group_public/download.php/124286/livelink
<IP_ADDRESS>.2 Processing unmap requests

Application clients use unmap commands (see 4.2.2) to request that LBAs be unmapped. For each LBA that
is requested to be unmapped, the device server shall:

    a) perform an unmap operation (see <IP_ADDRESS>.3) on the LBA; or
    b) make no change to the logical block provisioning state of the LBA.

Page 232 of SCSI Commands Reference Manual
https://www.seagate.com/files/staticfiles/support/docs/manual/Interface manuals/100293068j.pdf
3.54.2 UNMAP parameter list

The UNMAP parameter list (see table 205) contains the data sent by an application client along with an UNMAP command.
Included in the data are an UNMAP parameter list header and block descriptors for LBA extents to be processed by the device
server for the UNMAP command. The LBAs specified in the block descriptors may contain overlapping extents, and may be in
any order.

For each specified LBA:

    a) a mapped LBA should be unmapped (see SBC-4), or may remain mapped; and
    b) an unmapped LBA shall remain unmapped.

We probably don't need to (since the UNMAP only affects the volume head, which is RW for all replicas during a rebuild). Testing whether this is the case is probably the best path forward for this issue.

Agree. And based on the description of SCSI commands, it seems that Longhorn should do nothing rather than return an error when the unmap command cannot be processed.

Testing with not returning an error first.
This minor change in longhorn-engine is promising.
https://github.com/longhorn/longhorn-engine/compare/master...ejweber:7103-return-success-when-cannot-unmap?expand=1
fstrim while rebuilding does not actually unmap blocks and returns with no error. There is also no error in instance-manager or in the kernel ring buffer. After rebuilding is complete, ext4 remembers which blocks it already trimmed and refuses to try to trim them again, so no space can be reclaimed.
# During rebuilding.
root@test-pod:/# fstrim -va
/data: 4.7 GiB<PHONE_NUMBER> bytes) trimmed on /dev/longhorn/pvc-bc6cc450-72ad-46b2-b2c2-d7fb5d0733ae

# After rebuilding.
root@test-pod:/# fstrim -va
/data: 0 B (0 bytes) trimmed on /dev/longhorn/pvc-bc6cc450-72ad-46b2-b2c2-d7fb5d0733ae

However, after remounting the file system, fstrim issues unmounts again, and space is freed.
eweber@laptop:~/issue-files/7103> kubectl delete pod test-pod
pod "test-pod" deleted

eweber@laptop:~/issue-files/7103> k apply -f test.yaml
persistentvolumeclaim/test-pvc unchanged
pod/test-pod created

eweber@laptop:~/issue-files/7103> k exec -it test-pod -- bash

root@test-pod:/# fstrim -va
/data: 4.7 GiB<PHONE_NUMBER> bytes) trimmed on /dev/longhorn/pvc-bc6cc450-72ad-46b2-b2c2-d7fb5d0733ae

# Actual size reduces from 9.xx GiB to 5.22 GiB.

There is also no error in instance-manager or in the kernel ring buffer. After rebuilding is complete, ext4 remembers which blocks it already trimmed and refuses to try to trim them again, so no space can be reclaimed.

IIRC, we encountered this issue before but I am not sure if that's the reason why we return an error when the trim cannot be handled.

@shuo-wu, can you help to clarify the following point?
I was working off the assumption that UNMAP only affected the volume head. However, after digging deeper, I am understanding that it affects the volume head AND all removed snapshots.

https://github.com/longhorn/longhorn-engine/blob/067f67803ee85a0cced74f76f1826799aa4fe4e6/pkg/replica/replica.go#L1305-L1331
https://longhorn.io/docs/1.6.0/nodes-and-volumes/volumes/trim-filesystem/#the-global-setting-remove-snapshots-during-filesystem-trim

If I understand correctly, these means allowing an UNMAP during a rebuild would be dangerous.

First the volume-head is synchronized. All replicas (including the rebuilding one) have the same contents in volume-head, so it is safe to punch holes in volume-head while a rebuild is ongoing.
Then, all other differencing disks are synchronized. Some of these differencing disks may be removed snapshots. RW replicas will have holes punched in all removed disks.

Maybe holes will be punched at the same time a replica is sending one of these removed disks.
Maybe holes will be punched after one of these removed disks is synchronized (in which case I THINK the holed won't be punched in the rebuilding replica's copy?).

So I am thinking we were correct to disallow UNMAP during rebuild in our initial implementation, and we should not attempt to change that behavior now.
I'm fairly new to working with this aspect of Longhorn. Is there something I'm missing?

I tried https://github.com/longhorn/longhorn/issues/7103#issuecomment-1927223294 in two scenarios (basic steps in https://github.com/longhorn/longhorn/issues/7103#issue-1993659460):
Scenario 1 - remove-snapshots-during-filesystem-trim == false
Nothing particularly interesting happened. The snapshot just behind volume-head is NOT marked as removed during the rebuild, so UNMAP only affects volume-head. In my case, volume-head was empty (because I was not writing during the rebuild), so no blocks were unmapped.
Scenario 2 - remove-snapshots-during-filesystem-trim == true
When I issued the fstrim command, the snapshot behind volume head was marked as removed. The engine's instance manager logged the following, because the rebuilding replica did not yet have the removed snapshot to trim from:
[instance-manager-082ed51c98f6227cd7ad985a3a912171] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-r-4ccb4214] time="2024-02-05T16:03:43Z" level=info msg="Running ssync server for file volume-snap-13d2d691-14ef-4956-b944-fcb663380592.img at port 10004" func="rpc.(*SyncAgentServer).launchReceiver.func1" file="server.go:407"
[instance-manager-082ed51c98f6227cd7ad985a3a912171] time="2024-02-05T16:03:43Z" level=info msg="Creating Ssync service" func=rest.Server file="server.go:79"
[instance-manager-082ed51c98f6227cd7ad985a3a912171] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-r-4ccb4214] time="2024-02-05T16:03:43Z" level=info msg="file volume-snap-13d2d691-14ef-4956-b944-fcb663380592.img does not exist" func=rest.Server file="server.go:92"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-r-094ccdf7] time="2024-02-05T16:03:43Z" level=info msg="Syncing file volume-snap-13d2d691-14ef-4956-b944-fcb663380592.img to <IP_ADDRESS>:10004" func="rpc.(*SyncAgentServer).FileSend" file="server.go:343"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] time="2024-02-05T16:03:43Z" level=info msg="Syncing file volume-snap-13d2d691-14ef-4956-b944-fcb663380592.img to <IP_ADDRESS>:10004: size<PHONE_NUMBER>0, directIO true, fastSync true" func=sparse.SyncFile file="client.go:110"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] time="2024-02-05T16:03:43Z" level=warning msg="Failed to get change time and checksum of local file volume-snap-13d2d691-14ef-4956-b944-fcb663380592.img" func=sparse.SyncContent file="client.go:149" error="failed to open checksum file: open volume-snap-13d2d691-14ef-4956-b944-fcb663380592.img.checksum: no such file or directory"
[instance-manager-082ed51c98f6227cd7ad985a3a912171] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-r-4ccb4214] time="2024-02-05T16:03:43Z" level=info msg="Receiving volume-snap-13d2d691-14ef-4956-b944-fcb663380592.img: size<PHONE_NUMBER>0, directIO true" func="rest.(*SyncServer).doOpen" file="handlers.go:103"
[instance-manager-082ed51c98f6227cd7ad985a3a912171] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-r-4ccb4214] time="2024-02-05T16:03:43Z" level=info msg="Ssync server is opened and ready for receiving file volume-snap-13d2d691-14ef-4956-b944-fcb663380592.img" func="rest.(*SyncServer).open" file="handlers.go:84"
[instance-manager-082ed51c98f6227cd7ad985a3a912171] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-r-4ccb4214] time="2024-02-05T16:04:12Z" level=info msg="Reloading the revision counter before processing the first write, the current revision cache is 0, the latest revision counter in file is 0" func="replica.(*Replica).increaseRevisionCounter" file="revision_counter.go:133"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:12Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 4096" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:12Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 117440512" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:12Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 125829120" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 134217728" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 125829120" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 134217728" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 125829120" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 134217728" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 125829120" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 134217728" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 134217728" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 134217728" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 134217728" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 134217728" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 134217728" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 134217728" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 134217728" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 134217728" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 134217728" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 125829120" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 134217728" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 134217728" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 134217728" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 134217728" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 134217728" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 134217728" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-e-0] time="2024-02-05T16:04:13Z" level=warning msg="One of the MultiUnmapper get different size 0 from others 134217728" func="controller.(*MultiUnmapperAt).UnmapAt.func1" file="multi_unmapper_at.go:60"
[instance-manager-082ed51c98f6227cd7ad985a3a912171] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-r-4ccb4214] time="2024-02-05T16:05:42Z" level=info msg="Closing Ssync server" func="rest.(*SyncServer).close" file="handlers.go:165"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-r-094ccdf7] time="2024-02-05T16:05:42Z" level=info msg="Finished sync for the source file volume-snap-13d2d691-14ef-4956-b944-fcb663380592.img, size<PHONE_NUMBER>0, elapsed 119.35s" func=sparse.SyncContent file="client.go:171"
[instance-manager-082ed51c98f6227cd7ad985a3a912171] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-r-4ccb4214] time="2024-02-05T16:05:42Z" level=info msg="Done running ssync server for file volume-snap-13d2d691-14ef-4956-b944-fcb663380592.img at port 10004" func="rpc.(*SyncAgentServer).launchReceiver.func1" file="server.go:412"
[instance-manager-082ed51c98f6227cd7ad985a3a912171] time="2024-02-05T16:05:42Z" level=info msg="Running ssync server for file volume-snap-13d2d691-14ef-4956-b944-fcb663380592.img.meta at port 10005" func="rpc.(*SyncAgentServer).launchReceiver.func1" file="server.go:407"
[instance-manager-413dddc5cbb0881de748c6d4eb6b5553] [pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-r-094ccdf7] time="2024-02-05T16:05:42Z" level=info msg="Done syncing file volume-snap-13d2d691-14ef-4956-b944-fcb663380592.img to <IP_ADDRESS>:10004" func="rpc.(*SyncAgentServer).FileSend" file="server.go:347"

Once the rebuild was complete, I checked the files on replica files on disk for a mismatch.
eweber@laptop:~/liblonghorn> kl get replica -oyaml | grep -ie creationTimestamp -e directory -e " name:"
    creationTimestamp: "2024-02-05T15:42:47Z"
    name: pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-r-094ccdf7
      name: pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e
    dataDirectoryName: pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-6bb570a4
    creationTimestamp: "2024-02-05T15:42:47Z"
    name: pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-r-12f62800
      name: pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e
    dataDirectoryName: pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-ab058c6b
    creationTimestamp: "2024-02-05T16:03:31Z"
    name: pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-r-4ccb4214
      name: pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e
    dataDirectoryName: pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-cfcd557c

eweber@laptop:~/liblonghorn> kl exec -it instance-manager-082ed51c98f6227cd7ad985a3a912171 -- bash -c "du -h /host/var/lib/longhorn/replicas/pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-*/*"
4.0K    /host/var/lib/longhorn/replicas/pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-cfcd557c/revision.counter
0       /host/var/lib/longhorn/replicas/pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-cfcd557c/volume-head-001.img
4.0K    /host/var/lib/longhorn/replicas/pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-cfcd557c/volume-head-001.img.meta
9.5G    /host/var/lib/longhorn/replicas/pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-cfcd557c/volume-snap-7ca3f397-904c-4925-a30c-291a324e38a5.img
4.0K    /host/var/lib/longhorn/replicas/pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-cfcd557c/volume-snap-7ca3f397-904c-4925-a30c-291a324e38a5.img.meta
4.0K    /host/var/lib/longhorn/replicas/pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-cfcd557c/volume.meta
eweber@laptop:~/liblonghorn> kl exec -it instance-manager-413dddc5cbb0881de748c6d4eb6b5553 -- bash -c "du -h /host/var/lib/longhorn/replicas/pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-*/*"
4.0K    /host/var/lib/longhorn/replicas/pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-6bb570a4/revision.counter
0       /host/var/lib/longhorn/replicas/pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-6bb570a4/volume-head-003.img
4.0K    /host/var/lib/longhorn/replicas/pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-6bb570a4/volume-head-003.img.meta
5.3G    /host/var/lib/longhorn/replicas/pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-6bb570a4/volume-snap-7ca3f397-904c-4925-a30c-291a324e38a5.img
4.0K    /host/var/lib/longhorn/replicas/pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-6bb570a4/volume-snap-7ca3f397-904c-4925-a30c-291a324e38a5.img.meta
4.0K    /host/var/lib/longhorn/replicas/pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-6bb570a4/volume.meta
eweber@laptop:~/liblonghorn> kl exec -it instance-manager-699da83c0e9d22726e667344227e096b -- bash -c "du -h /host/var/lib/longhorn/replicas/pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-*/*"
4.0K    /host/var/lib/longhorn/replicas/pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-ab058c6b/revision.counter
0       /host/var/lib/longhorn/replicas/pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-ab058c6b/volume-head-003.img
4.0K    /host/var/lib/longhorn/replicas/pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-ab058c6b/volume-head-003.img.meta
5.3G    /host/var/lib/longhorn/replicas/pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-ab058c6b/volume-snap-7ca3f397-904c-4925-a30c-291a324e38a5.img
4.0K    /host/var/lib/longhorn/replicas/pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-ab058c6b/volume-snap-7ca3f397-904c-4925-a30c-291a324e38a5.img.meta
4.0K    /host/var/lib/longhorn/replicas/pvc-bae950ef-b641-4fcc-82c2-243348ff0b2e-ab058c6b/volume.meta

The snapshot file for the newly rebuilt replica uses much more disk space than the others (which were successfully trimmed). As far as I can tell so far, this is not actually problematic from a data integrity perspective, but I still don't think we should allow replicas to become out-of-sync like this.

Given this discussion, I think there are now two goals for this issue:

[ ] Modify longhorn-engine code so we do NOT return an error when an UNMAP is issued on rebuild we we DO refuse to actually do the UNMAP. This is legal according to the SCSI standard and will prevent really annoying issues in Harvester.
[ ] Update our documentation to make the effects of this change clear. There is already mention that the user may need to remount the filesystem to make a trim effective in some situations. This is another situation in which that might be the case.

Verified passed on master-head (longhorn-engine 5bd31c0) following the test steps.


fix: onChange method description to be accurate

current description of onChange gives an impression of some sort of websocket/realtime update capability, but that's not the case

Sure ok, valid point.


Better error message when referencing a component that is not required properly

Hello, I think this is definitely a nice to have but could make development for people starting with React-Native a lot better. There's been a few times while working through the API where I have not properly required the new component I'm learning and I get hit with an error message that looks as such:

It'd be really great to have a nice hint for folks. Your console for web react already does a great job of this. In any event, thank you for your hard work on all of these projects.

We'll track this in #1569.


Add a link to https://github.com/zupo/awesome-pytest-speedup

Thanks :-)

I actually just read https://maurits.vanrees.org/weblog/archive/2022/10/fast-tests yesterday

I actually just read https://maurits.vanrees.org/weblog/archive/2022/10/fast-tests yesterday

The talk recording is already online! https://www.youtube.com/watch?v=uvkSOaFYsLo
Also, hey!! 👋 👋 , it's been a long time! :)


Feature/nextflow temporary dag tool listing

Prototype nextflow dag and tool listing with tests
code will need to be replaced with NextFlow code after license change, but gets us something sane looking for now

Coverage increased (+0.1%) to 75.984% when pulling a2b21d1a53269de7320bb4659c4f14abb6ac707b on feature/nextflow_temporary_dag_tool_listing into d4dd5028949905272934356648cde280ee4c8cd8 on develop.


[Sync] - Last sync date doesn't update

Describe the bug
The app doesn't immediately update the sync date upon a successful sync, this happens event when the sync has been successful and the local resources pushed to HAPI
To Reproduce
Steps to reproduce the behavior:

Log into FHIRCore app
Add a new resource record, and query local SQLite to pick resource id
Sync the app to push resources to the server
Query the above id in HAPI to check the lastUpdated
Compare the datetime with the last sync date in the app

Expected behavior
Updated last sync date immediately after the sync is completed and successfully
Screenshots
If applicable, add screenshots to help explain your problem.
Smartphone (please complete the following information):

tested on emulator

Additional context
See the screenshot below the app vs the resource sync time

{
	"resourceType": "Patient",
	"id": "5a41a9cd-657b-4b77-a8fc-c2b756deeb53",
	"meta": {
		"lastUpdated": "2023-05-26T23:23:07.291+03:00",
		"tag": [
			{
				"system": "https://smartregister.org/",
				"code": "0.2.3-echis",
				"display": "Application Version"
			},
			{
				"system": "https://smartregister.org/",
				"code": "0.2.3-echis",
				"display": "Application Version"
			},
			{
				"system": "https://smartregister.org/",
				"code": "698acddb-36d6-44aa-a266-603756cb7545",
				"display": "Practitioner CareTeam"
			},
			{
				"system": "https://smartregister.org/",
				"code": "1599cdb2-2239-43e0-8403-60d6fbe85794",
				"display": "Practitioner Location"
			},
			{
				"system": "https://smartregister.org/",
				"code": "75a1be9b-93fb-4b97-956f-27f56ba92a3c",
				"display": "Practitioner Organization"
			},
			{
				"system": "https://smartregister.org/",
				"code": "6edaafb0-0212-4069-a0e2-c6a90a080c83",
				"display": "Practitioner"
			}
		]
	},
	"identifier": [
		{
			"use": "official",
			"type": {
				"coding": [
					{
						"system": "http://ona.io/codes",
						"code": "id_category",
						"display": "Nationality Type"
					}
				],
				"text": "Ugandan National"
			}
		},
		{
			"use": "secondary",
			"value": "e6347340-b83c-4a67-b28a-8aeb638c948d",
			"period": {
				"start": "2023-05-26T23:23:06+03:00"
			}
		}
	],
	"active": true,
	"name": [
		{
			"use": "official",
			"text": "Kwacha",
			"family": "Cess"
		}
	],
	"telecom": [
		{
			"system": "phone"
		}
	],
	"gender": "male",
	"birthDate": "2021-05-26",
	"deceasedBoolean": false,
	"generalPractitioner": [
		{
			"reference": "Practitioner/6edaafb0-0212-4069-a0e2-c6a90a080c83"
		}
	],
	"managingOrganization": {
		"reference": "Organization/75a1be9b-93fb-4b97-956f-27f56ba92a3c"
	}
}

From the user perspective, the timestamp indicates when the last data was successfully synced to the server side, if this is true then this is currently the only indicator for the user to determine when last they had a successful sync.
The current challenge is that FHIRCore sync each resource independently, so should this time be the time of the last successfully synced resource or define it based on some algorithm for sets of resources synced successfully.
A further sync stats page will be more useful to user and can eliminate data loss for just relying on the toast message and the timestamp

@ellykits I think this is inline with the conversation we had on what should constitutes the Last Timestamp shown on the app

@qiarie take note of this

@qiarie are you working on this issue
cc @ellykits

currently the sync timestamp updates correctly, this need understanding for better training on the meaning of the date for end users


special-character-001 PNG missing

Thanks for spotting that this File is Missing! We will add it asap.


Timesheet - 14/04/2021 - Usman Khalid

Task 1
Reviewed the PR for the website repo for Quality Assurance.
Proof of Work

https://github.com/thenewboston-developers/Website/pull/1706

Time Spent
1h
Account Number
86cbaa1e021cc7d21ceedefc493051004c5ffffbc09a4ecd25e3a8dc49975d3e

Hey, @Rajputusman we are using 0.5 hours as the unit. Should we make it 1 hour instead of 45 minutes?

@manishram Okay

Approved

Approved


Mat/Pat - add bullet in email to applicants about pension

AC

[ ] Add this as the 3rd point in the email sent to applicants after approval (before income tax)

You have the option to make continuous pension contributions monthly throughout your leave.  You must decide within the first 30 days of your leave and submit a completed Purchase of Service Application through an AskMyHR Service request.  Use the category Myself > Benefits > Pension/Purchase of Service.

@ayushdamani
Added bullet point as per this ticket. It is ready to test on TEST environment.

looks good

looks good

Live email came through with bullet yay re-closing


Force install of VSTeam Module

PR Summary
Force install of VSTeam Module.
I've seen that it failed on the Install VSTeam Module step recently (The build that is currently listed on the "Build" badge on the README is failing on this)
Fixes #248
PR Checklist

[ ] Write Help
[ ] Write Unit Test
[ ] Update CHANGELOG.md

(not necessary)

Find this strange. Did you see it fail every time or is it flaky? Do you have an idea why this fixes it?

I think flaky. Can‘t hurt to add it :)

I noticed it on the lateste hosted linux build agents. When I forced to 16.04 it stopped failing. But I am fine adding this as well.


[KYUUBI #2929] Kyuubi integrated Ranger does not support the CTAS syntax

Why are the changes needed?

close https://github.com/apache/incubator-kyuubi/issues/2929#issue-1279486176
How was this patch tested?

[x] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[ ] Run test locally before make a pull request

Codecov Report

Merging #2931 (d9cca71) into master (825c70d) will decrease coverage by 0.01%.
The diff coverage is 66.66%.

@@             Coverage Diff              @@
##             master    #2931      +/-   ##
============================================
- Coverage     62.91%   62.89%   -0.02%
  Complexity        6        6
============================================
  Files           418      418
  Lines         20277    20277
  Branches       2593     2593
============================================
- Hits          12757    12753       -4
- Misses         6285     6286       +1
- Partials       1235     1238       +3

Impacted Files
Coverage Δ

.../kyuubi/plugin/spark/authz/PrivilegesBuilder.scala
69.13% <66.66%> (ø)

...rg/apache/kyuubi/ctl/cmd/log/LogBatchCommand.scala
80.00% <0.00%> (-2.00%)
:arrow_down:

.../org/apache/kyuubi/operation/KyuubiOperation.scala
68.00% <0.00%> (-1.34%)
:arrow_down:

.../engine/spark/session/SparkSQLSessionManager.scala
79.01% <0.00%> (-1.24%)
:arrow_down:

...n/scala/org/apache/kyuubi/engine/ProcBuilder.scala
83.12% <0.00%> (-0.63%)
:arrow_down:

Continue to review full report at Codecov.

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

cc @MLikeWater

cc @MLikeWater

Thanks.


Update .openpublishing.redirection.delete-service-page.json

Redirects for change of service name for az healthcareapis command group.

@dbradish-microsoft Thank you so much for creating this PR and getting it out to PROD!

[celebrate]     Jason Steppe reacted to your message:

From: Delora Bradish @.>
Sent: Thursday, November 21, 2024 8:27:04 PM
To: MicrosoftDocs/azure-docs-cli @.>
Cc: Jason Steppe @.>; Comment @.>
Subject: Re: [MicrosoftDocs/azure-docs-cli] Update .openpublishing.redirection.delete-service-page.json (PR #4796)
Merged #4796https://github.com/MicrosoftDocs/azure-docs-cli/pull/4796 into main.
—
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/azure-docs-cli/pull/4796#event-15388039065, or unsubscribehttps://github.com/notifications/unsubscribe-auth/APR4ILI6NROH3BUZFKWNS332BY6ZRAVCNFSM6AAAAABSHFXRXKVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJVGM4DQMBTHEYDMNI.
You are receiving this because you commented.Message ID: @.***>


Docs: mark up contents ASCII trees as semantically meaningful nested lists

Possibly a work in progress, but: currently, we use ASCII art trees to show directory structures. This is completely nonsensical/meaningless to non-visual (e.g. screenreader) users. We either need to provide an alternative, or try and provide some semantic structure. This PR formalizes an idea I had a while ago https://codepen.io/patrickhlauke/pen/azbYWZ to use nested lists and generated CSS content to mimic the current look, while having proper structure.
It could probably do with more styling to make it a block/have proper background, and to get the correct monospace font applied to, say, <pre> ... but putting this here as an initial exploration.

Comparison of the ASCII approach (left) and the new approach (right):

Huh, I've always wondered about this. 😆 Props for digging in and finding a solution. Looking at the amount of CSS though, maybe we switch to a table and describe the folder contents that way?

@mdo

Looking at the amount of CSS
I think we can drop the "level 4" part of the CSS (left it in there to be a bit more future-proof just in case). In the grand scheme of things it doesn't look too excessive to me.

maybe we switch to a table and describe the folder contents that way?
how would you convey the nested hierarchy in a data table?

how would you convey the nested hierarchy in a data table?

I think the only thing we need to convey is that there is css/ and js/, and there are multiple bundles in each of those. For example:

Directory
Description

css/
Compiled CSS, minified CSS, and source maps for our default, grid, and Reboot bundles

js/
Compiled and minified JavaScript plugins with an optional bundle that includes our dependencies

Descriptions would need work mind you.

table like that would start getting difficult for anything with more levels, like http://getbootstrap.com/docs/4.0/getting-started/contents/#bootstrap-source-code and http://getbootstrap.com/docs/4.0/getting-started/theming/#file-structure though


✨ Add support for external plugins

Codecov Report

Merging #25 into 1.0.4 will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##             1.0.4       #25   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            1         1
  Lines           14        17    +3
  Branches         0         1    +1
=========================================
+ Hits            14        17    +3

Impacted Files
Coverage Δ

src/vue-markdown-it.js
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Development tab will sometimes not sync.

Specifically in jira under development tab pr will show open but in git it is merged. Is there a work around for this?

Can you try restarting the sync in the Github app configuration?  We believe we've fixed and issue and resyncing it should show the correct data again.  Thanks!

I will give this a try may take a bit since i dont have permissions. Do i need to do this to resolve future issues or is just for the issues that are already not synced?

@JOcampoCR This is just a one time fix as we've identified something that didn't sync in the past.  From now on, everything should work as intended.

Hey @JOcampoCR. Do you need any further assistance on this one?

Hey @JOcampoCR. As we haven’t heard from you in almost 2 months, I’m going to go ahead and close this issue. Please feel free to reopen if you still need assistance.


Bugfix: Tar files created in their target directory shouldn't recurse infinitely

This addresses #383 .
Happy to refactor however you like, and open to any feedback. Thank you!

Thanks for the patch! I have not encountered this situation so I appreciate the test case. Is the right behavior really to just skip the file?

Yep! At least to the best of my knowledge skipping this sub '.' entry keeps everything going, correctly. I tested it on some random archives here and they all behaved correctly with that weird entry being completely skipped.


Crash when I create an APNGImage with data and scale (On Clean)

It's crashing on this line:
https://github.com/onevcat/APNGKit/blob/252ae33500e8faabb67caeea4a93ea7e50ae98fc/APNGKit/Disassembler.swift#L460
It's a valid png image
"bad adaptive filter value" is logged out
Other times "libpng error: IDAT: CRC error" is logged out
Context: Many APNGImageViews are being used in collection view cells (reused)

Does this happen 100% for a specified PNG file, or is it random?

@onevcat   It's random on different PNG files.  I have a feeling it could have to do with cell reuse, but I could be wrong.

APNGKit v2 was release and it now does not depend on libpng. So this should not happen anymore.


Issue parsing APIGateway Event

Expected behavior
Expected my lambda to return a APIGatewayV2Response along with my body
Actual behavior
Found the following in the CloudWatch Logs
2022-04-25T15:40:54+0000 warning Lambda : lifecycleIteration=1 lambda handler returned an error: requestDecoding(Swift.DecodingError.keyNotFound(CodingKeys(stringValue: "version", intValue: nil), Swift.DecodingError.Context(codingPath: [], debugDescription: "No value associated with key CodingKeys(stringValue: \"version\", intValue: nil) (\"version\").", underlyingError: nil)))

Steps to reproduce

Use the Deployment Lambda found in the Examples dir and deployed to AWS using APIGateway with a Lambda_PROXY
make an HTTP call to your APIGateway
Observe the errors in the CloudWatch Log

If possible, minimal yet complete reproducer code (or URL to code)
serverless.yml
service: helloworld-swift-aws

provider:
    name: aws
    runtime: provided
    region: us-east-2

package:
    artifact: .build/lambda/HelloWorld/lambda.zip

functions:
    hello:
        handler: HelloWorld
        memorySize: 128
        events:
          - http:
              method: ANY
              path: /{proxy+}
              cors: true

SwiftAWSLambdaRuntime version/commit hash
main branch
Swift & OS version (output of swift --version && uname -a)
Apple Swift version 5.6 (swiftlang-<IP_ADDRESS>3.62 clang-13<IP_ADDRESS>)
MacOS Monterrey 12.3.1

I create a PR #16

I think this issue can be closed @fabianfett

I think this issue can be closed  @tomerd @tachyonics

fixed via #18


De-couple Wireguard requirement

Any reason you are hard-coding Wireguard in the compose orchestration? I get why you might want to use a VPN to grab certain data/scrapes, but IMO it should be up to the operator to take care of this and they might already have something they're using (think Gluetun, or VPN via egress routes).

I basically just kept the compose I've been using for dev, I'll simplify it to offer an out of the box docker without VPN

Done


inspect-builder does not represent optionality of buildpacks within groups.

Currently when pack inspect-builder is run, it lists the buildpacks in a group, but does not describe their optionality.
  Group #1:
    org.cloudfoundry.openjdk@latest
    org.cloudfoundry.buildsystem@latest
    io.projectriff.java@latest
    org.cloudfoundry.azureapplicationinsights@latest
    org.cloudfoundry.debug@latest
    org.cloudfoundry.googlestackdriver@latest
    org.cloudfoundry.jmx@latest
    org.cloudfoundry.procfile@latest

represented by
[[groups]]
labels = [ "java", "riff" ]
buildpacks = [
  { id = "org.cloudfoundry.openjdk",                  version = "latest" },
  { id = "org.cloudfoundry.buildsystem",              version = "latest", optional = true },
  { id = "io.projectriff.java",                       version = "latest" },

  { id = "org.cloudfoundry.azureapplicationinsights", version = "latest", optional = true },
  { id = "org.cloudfoundry.debug",                    version = "latest", optional = true },
  { id = "org.cloudfoundry.googlestackdriver",        version = "latest", optional = true },
  { id = "org.cloudfoundry.jmx",                      version = "latest", optional = true },

  { id = "org.cloudfoundry.procfile",                 version = "latest", optional = true },
]

The optionality of the buildpacks in each group should be represented in the output.

After speaking w/ @djoyahoy, we're holding off on testing this until optionality can be reflected when running pack inspect-builder on the builders a user sees when they run pack suggest-builders

Disregard my above comment, optionality shows up with remote builders, but the suggested builders don't have optionality.  Accepting this story.

done on master will ship in v0.2.0


[MB-8827] Bump storybook-related dependencies to 6.3.6

Description
This PR consolidates the following dependabot PRs related to upgrading Storybook to version 6.3.6:
#7068
#7066
#7063
#7061
#7060
Setup
Just need to ensure the tests and build pass with no issues.

Messages

:book:
:link: MB-8827

  Generated by :no_entry_sign: dangerJS against 822e9a2a4009fb08faf5fa03ce3c70fc897a2d6b

Can a front-end person confirm the happo diffs are okay? Especially the document viewer one (the diff shows it as loading instead of present)
cc: @YanZ777 @jenniferlynparsons


bump dependency versions

Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

[X] Has your PR been rebased against the latest commit within the target branch (typically develop)?

[X] Is your initial contribution a single, squashed commit?

[X] Does gradlew build run cleanly?

[N/A] Have you written or updated unit tests to verify your changes?

[N/A] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

Note:
Please ensure that once the PR is submitted, check Concourse for build issues and
submit an update to your PR as soon as possible. If you need help, please send an
email to<EMAIL_ADDRESS>

Leaving Mockito at v0.23.x since later versions cause OOM in HARegionQueueIntegrationTest.

@metatype I’d ask that you open a JIRA to fix this test and upgrade Mockito.

Also backing out the Jedis upgrade.

@metatype I’d ask that you open a JIRA to fix this test and upgrade Mockito.

See GEODE-6590.

this received a passing review...please rebase to latest develop so checks can re-run

This PR appears to have been abandoned.  It will be closed in 72 hours if there is no further activity.

closed due to inactivity


fix: respect isEncrypted:false if supplied in notify: command, and ensure the correct value is always transmitted onwards

- What I did
fix: respect isEncrypted:false if supplied in notify: command, and ensure the correct value is always transmitted onwards
Addresses at_server parts of #1944
- How I did it
See commits
- How to verify it

[x] at_server automated tests pass
[x] manually verified that noports e2e tests pass when running against this branch's version of atServer
[x] manually verified that at_client_sdk e2e tests pass when running against this branch's version of atServer

Converted to draft as I need to add some unit tests to ensure this doesn't regress in the future

Converted to draft as I need to add some unit tests to ensure this doesn't regress in the future

@sitaram-kalluri Have added some unit tests. Please review when you have a moment, thank you.


RapiD support

Any way to get this working on RapiD?

Seems like there already is another extension that does this for RapiD


Get-GitlabMergeRequest Update

Added default of . to Get-GitlabMergeRequest for project
Updated Get-LocalGitContext to deal with Detached HEAD
Added Branch filter on function too

Thanks @CaseyMacPherson for the contribution -- I've been thinking about wanting a get-mr alias that would either create, or get the MR for the current git context -- this gets us a lot closer to doing that!


Feature/traffic sign codes import

Import Traffic Sign Codes from CSV-file.

Add Traffic Sign Code REST API
Add custom Django management command for importing Traffic Sign Codes
Use Django test client to input data through REST API instead of direct db-input

Refs LIIK-30, LIIK-49

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@d45640f). Click here to learn what that means.
The diff coverage is 97.89%.

@@            Coverage Diff            @@
##             master      #20   +/-   ##
=========================================
  Coverage          ?   96.18%
=========================================
  Files             ?       33
  Lines             ?     1885
  Branches          ?       39
=========================================
  Hits              ?     1813
  Misses            ?       66
  Partials          ?        6

Impacted Files
Coverage Δ

city-infrastructure-platform/settings.py
84.21% <ø> (ø)

traffic_control/views.py
100% <100%> (ø)

traffic_control/tests/test_traffic_sign_api.py
100% <100%> (ø)

traffic_control/tests/test_base_api.py
100% <100%> (ø)

traffic_control/filters.py
100% <100%> (ø)

traffic_control/tests/factories.py
90.47% <90.47%> (ø)

Continue to review full report at Codecov.

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


Conflicting peer dependency<EMAIL_ADDRESS>from<EMAIL_ADDRESS>

Hi, even though the peer dependency has been updated #114 , I guess the @nest-zod/z does also need an update.
package.json
"nestjs-zod": "^4.2.0",
"@nestjs/swagger": "^8.0.7",

Warn:
npm warn ERESOLVE overriding peer dependency
npm warn While resolving<EMAIL_ADDRESS>npm warn Found<EMAIL_ADDRESS>npm warn node_modules/@nestjs/swagger
npm warn<EMAIL_ADDRESS>from the root project
npm warn   1 more (nestjs-zod)
npm warn
npm warn Could not resolve dependency:
npm warn peerOptional<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm warn node_modules/nestjs-zod/node_modules/@nest-zod/z
npm warn   @nest-zod/z@"*" from<EMAIL_ADDRESS>npm warn   node_modules/nestjs-zod
npm warn
npm warn Conflicting peer dependency<EMAIL_ADDRESS>npm warn node_modules/@nestjs/swagger
npm warn   peerOptional<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm warn   node_modules/nestjs-zod/node_modules/@nest-zod/z
npm warn     @nest-zod/z@"*" from<EMAIL_ADDRESS>npm warn     node_modules/nestjs-zod

👍


Add support for React hooks

Hi guys, cool project! I'm trying to migrate a basic Chakra + FastAPI app to Pynecone but a bit stuck on implementing the classic Chakra ColorModeSwitcher component.
Is there any way currently to access the color mode hooks? I imagine there are use cases beyond these hooks, but being able to use hooks from other libraries.
Example component to implement:
import * as React from "react"
import {
  useColorMode,
  useColorModeValue,
  IconButton,
  IconButtonProps,
} from "@chakra-ui/react"
import { FaMoon, FaSun } from "react-icons/fa"

type ColorModeSwitcherProps = Omit<IconButtonProps, "aria-label">

export const ColorModeSwitcher: React.FC<ColorModeSwitcherProps> = (props) => {
  const { toggleColorMode } = useColorMode()
  const text = useColorModeValue("dark", "light")
  const SwitchIcon = useColorModeValue(FaMoon, FaSun)

  return (
    <IconButton
      size="md"
      fontSize="lg"
      variant="ghost"
      color="current"
      marginLeft="2"
      onClick={toggleColorMode}
      icon={<SwitchIcon />}
      aria-label={`Switch to ${text} mode`}
      {...props}
    />
  )
}

Thanks for raising this issue.
Currently there's no good way to use your own React hooks in Pynecone. But this is a feature we want to add because like you said, there are other libraries that use hooks for functionality.
This change requires some core updates to the compiler, so may be a bit more involved. But we will add it to our roadmap.

This was added in #810


Upgrade 0.9.42

Upgrades the pallet to V0.9.42, the main changes are based on the modification to the balance_pallet and the fungibles traits as described in this PR on substrate.
The main change has to do with the removal of the Transfer trait which was merged into the Mutate trait and the inclusion/change of some parameters to some of the functions inside this trait.

I will also create a new branch once this is merged named polkadot-v0.9.42 so we can use it in other projects like Trappist.