Tuner "Stuck", not released by fHDHR?

Hi,
OK, I finally caught the case I have been chasing 😆. No solution yet, but to capture it here, by all means I'm open to suggestions!
The issue is that I see in the ceton API (status) shows tuner "1" as external - no stream args, but appears to be in use (file attached). Checking the fHDHR tuner status (also attached) ... it seems to be in use, for 12 hours?!?! But no stream args passed to the same ceton tuner object?
Have you seen this type of thing before? I'll keep digging, but it is a bit odd.
FYI, I can kill ffmpeg from the web UI, but when I try to stop the Ceton tuner ... it keeps restarting. And I don't see Plex using it - I can't seem to see where / if it's really used. Hmmm.
Thanks!
ceton.json.txt
tuners.json.txt

I've seen that pattern once or twice.  Restarting fhdhr cleared it.  Could be something is resetting the retry counter, but I have not figured out how/why yet either.

FYI, it seems there is a correlation between this "stuck" state and the output stream "stuttering" (choppy output). So it may be a bit more of an issue than just notification / information => actual performance impact of some sort.
Restarting fHDHR is the fix ... but I also find, when in this state - the restart is VERY slow (i.e. a minute or more).
Thanks!

OK, a bit more on this - have added some debug output, to try to find when this is happening. Very odd, but in the log I see this occurring ... thoughts? Really does seem to be an fHDHR related issue.

All within ~ 0.5 sec?

[2022-05-26 20:50:54,531] NOOB - [ceton] get_channel_stream ...
> stream_args: {"channel": "508", "channel_name": "WFAA ABC HD", "channel_callsign": "WFAA ABC HD", "origin_name": "ceton", "method": "ffmpeg", "duration": 0, "transcode_quality": "active", "tuner_number": null, "accessed": "http://<IP_ADDRESS>:5006/hdhr/ceton/auto/v508", "base_url": "http://<IP_ADDRESS>:5006", "client": "<IP_ADDRESS>", "client_id": "82ab713d-900c-4648-be75-94230cfb05b1", "origin_quality": null, "bytes_per_read": 1152000, "buffer_size": 3, "stream_restore_attempts": 3}
[2022-05-26 20:50:54,537] NOOB - [ceton] get_channel_stream ...
> stream_args: {"channel": "574", "channel_name": "ESPN 2 HD", "channel_callsign": "ESPN 2 HD", "origin_name": "ceton", "method": "ffmpeg", "duration": 0, "transcode_quality": "active", "tuner_number": null, "accessed": "http://<IP_ADDRESS>:5006/hdhr/ceton/auto/v574", "base_url": "http://<IP_ADDRESS>:5006", "client": "<IP_ADDRESS>", "client_id": "2f69610c-ffaf-4491-974c-7154b3aae3f7", "origin_quality": null, "bytes_per_read": 1152000, "buffer_size": 3, "stream_restore_attempts": 3}
[2022-05-26 20:50:54,634] NOOB - [ceton] get_channel_stream ...
> stream_args: {"channel": "508", "channel_name": "WFAA ABC HD", "channel_callsign": "WFAA ABC HD", "origin_name": "ceton", "method": "ffmpeg", "duration": 0, "transcode_quality": "active", "tuner_number": null, "accessed": "http://<IP_ADDRESS>:5006/hdhr/ceton/auto/v508", "base_url": "http://<IP_ADDRESS>:5006", "client": "<IP_ADDRESS>", "client_id": "cbe1d45e-2b69-4a2a-9743-78d8a66294fe", "origin_quality": null, "bytes_per_read": 1152000, "buffer_size": 3, "stream_restore_attempts": 3}
[2022-05-26 20:50:54,730] NOOB - [ceton] get_channel_stream ...
> stream_args: {"channel": "508", "channel_name": "WFAA ABC HD", "channel_callsign": "WFAA ABC HD", "origin_name": "ceton", "method": "ffmpeg", "duration": 0, "transcode_quality": "active", "tuner_number": null, "accessed": "http://<IP_ADDRESS>:5006/hdhr/ceton/auto/v508", "base_url": "http://<IP_ADDRESS>:5006", "client": "<IP_ADDRESS>", "client_id": "555bdc50-d4f6-42e4-88bd-4ada9e753447", "origin_quality": null, "bytes_per_read": 1152000, "buffer_size": 3, "stream_restore_attempts": 3}
[2022-05-26 20:50:54,890] NOOB - [ceton] get_channel_stream ...
> stream_args: {"channel": "574", "channel_name": "ESPN 2 HD", "channel_callsign": "ESPN 2 HD", "origin_name": "ceton", "method": "ffmpeg", "duration": 0, "transcode_quality": "active", "tuner_number": null, "accessed": "http://<IP_ADDRESS>:5006/hdhr/ceton/auto/v574", "base_url": "http://<IP_ADDRESS>:5006", "client": "<IP_ADDRESS>", "client_id": "e85463c0-e8b6-431a-9135-f5c546efb37b", "origin_quality": null, "bytes_per_read": 1152000, "buffer_size": 3, "stream_restore_attempts": 3}

Some sort of stuck loop? This goes on hundreds of times!

[2022-05-26 20:51:31,973] NOOB - [ceton] Initiate PCIe direct streaming, channel 508 from Ceton tuner#: 1
[2022-05-26 20:51:31,978] NOOB - [ffmpeg] Loaded transcoding configurations file, /mnt/raid/ProgRAID/fHDHR/plugins/fHDHR_plugin_stream_ffmpeg/transcode.json
[2022-05-26 20:51:31,979] NOOB - [ffmpeg] Client requested a active transcode for stream.
[2022-05-26 20:51:31,980] NOOB - [ffmpeg] ffmpeg command: ['/usr/bin/ffmpeg', '-hwaccel', 'cuda', '-deint', '1', '-hwaccel_output_format', 'cuda', '-i', '/dev/ceton/ctn91xx_mpeg0_1', '-reconnect', '1', '-reconnect_at_eof', '1', '-reconnect_streamed', '1', '-reconnect_delay_max', '2', '-vf', 'scale_cuda=1920:1080', '-c:v', 'hevc_nvenc', '-preset', 'p6', '-tune', 'hq', '-b:v', '3M', '-c:a', 'ac3', '-b:a', '196k', '-f', 'mpegts', '-nostats', '-hide_banner', '-loglevel', 'info', 'pipe:stdout']
[2022-05-26 20:51:32,302] NOOB - [ceton] Preparing Ceton tuner 1 on port: 8001
[2022-05-26 20:51:33,146] NOOB - [ceton] Initiate PCIe direct streaming, channel 554 from Ceton tuner#: 1
[2022-05-26 20:51:33,151] NOOB - [ffmpeg] Loaded transcoding configurations file, /mnt/raid/ProgRAID/fHDHR/plugins/fHDHR_plugin_stream_ffmpeg/transcode.json
[2022-05-26 20:51:33,152] NOOB - [ffmpeg] Client requested a active transcode for stream.
[2022-05-26 20:51:33,152] NOOB - [ffmpeg] ffmpeg command: ['/usr/bin/ffmpeg', '-hwaccel', 'cuda', '-deint', '1', '-hwaccel_output_format', 'cuda', '-i', '/dev/ceton/ctn91xx_mpeg0_1', '-reconnect', '1', '-reconnect_at_eof', '1', '-reconnect_streamed', '1', '-reconnect_delay_max', '2', '-vf', 'scale_cuda=1920:1080', '-c:v', 'hevc_nvenc', '-preset', 'p6', '-tune', 'hq', '-b:v', '3M', '-c:a', 'ac3', '-b:a', '196k', '-f', 'mpegts', '-nostats', '-hide_banner', '-loglevel', 'info', 'pipe:stdout']
[2022-05-26 20:51:33,217] NOOB - [ffmpeg] Loaded transcoding configurations file, /mnt/raid/ProgRAID/fHDHR/plugins/fHDHR_plugin_stream_ffmpeg/transcode.json
[2022-05-26 20:51:33,218] NOOB - [ffmpeg] Client requested a active transcode for stream.
[2022-05-26 20:51:33,219] NOOB - [ffmpeg] ffmpeg command: ['/usr/bin/ffmpeg', '-hwaccel', 'cuda', '-deint', '1', '-hwaccel_output_format', 'cuda', '-i', '/dev/ceton/ctn91xx_mpeg0_1', '-reconnect', '1', '-reconnect_at_eof', '1', '-reconnect_streamed', '1', '-reconnect_delay_max', '2', '-vf', 'scale_cuda=1920:1080', '-c:v', 'hevc_nvenc', '-preset', 'p6', '-tune', 'hq', '-b:v', '3M', '-c:a', 'ac3', '-b:a', '196k', '-f', 'mpegts', '-nostats', '-hide_banner', '-loglevel', 'info', 'pipe:stdout']
[2022-05-26 20:51:33,289] NOOB - [ffmpeg] Loaded transcoding configurations file, /mnt/raid/ProgRAID/fHDHR/plugins/fHDHR_plugin_stream_ffmpeg/transcode.json
[2022-05-26 20:51:33,290] NOOB - [ffmpeg] Client requested a active transcode for stream.
[2022-05-26 20:51:33,291] NOOB - [ffmpeg] ffmpeg command: ['/usr/bin/ffmpeg', '-hwaccel', 'cuda', '-deint', '1', '-hwaccel_output_format', 'cuda', '-i', '/dev/ceton/ctn91xx_mpeg0_1', '-reconnect', '1', '-reconnect_at_eof', '1', '-reconnect_streamed', '1', '-reconnect_delay_max', '2', '-vf', 'scale_cuda=1920:1080', '-c:v', 'hevc_nvenc', '-preset', 'p6', '-tune', 'hq', '-b:v', '3M', '-c:a', 'ac3', '-b:a', '196k', '-f', 'mpegts', '-nostats', '-hide_banner', '-loglevel', 'info', 'pipe:stdout']
[2022-05-26 20:51:33,361] NOOB - [ffmpeg] Loaded transcoding configurations file, /mnt/raid/ProgRAID/fHDHR/plugins/fHDHR_plugin_stream_ffmpeg/transcode.json
[2022-05-26 20:51:33,362] NOOB - [ffmpeg] Client requested a active transcode for stream.
[2022-05-26 20:51:33,363] NOOB - [ffmpeg] ffmpeg command: ['/usr/bin/ffmpeg', '-hwaccel', 'cuda', '-deint', '1', '-hwaccel_output_format', 'cuda', '-i', '/dev/ceton/ctn91xx_mpeg0_1', '-reconnect', '1', '-reconnect_at_eof', '1', '-reconnect_streamed', '1', '-reconnect_delay_max', '2', '-vf', 'scale_cuda=1920:1080', '-c:v', 'hevc_nvenc', '-preset', 'p6', '-tune', 'hq', '-b:v', '3M', '-c:a', 'ac3', '-b:a', '196k', '-f', 'mpegts', '-nostats', '-hide_banner', '-loglevel', 'info', 'pipe:stdout']
[2022-05-26 20:51:33,437] NOOB - [ffmpeg] Loaded transcoding configurations file, /mnt/raid/ProgRAID/fHDHR/plugins/fHDHR_plugin_stream_ffmpeg/transcode.json
[2022-05-26 20:51:33,438] NOOB - [ffmpeg] Client requested a active transcode for stream.
[2022-05-26 20:51:33,439] NOOB - [ffmpeg] ffmpeg command: ['/usr/bin/ffmpeg', '-hwaccel', 'cuda', '-deint', '1', '-hwaccel_output_format', 'cuda', '-i', '/dev/ceton/ctn91xx_mpeg0_1', '-reconnect', '1', '-reconnect_at_eof', '1', '-reconnect_streamed', '1', '-reconnect_delay_max', '2', '-vf', 'scale_cuda=1920:1080', '-c:v', 'hevc_nvenc', '-preset', 'p6', '-tune', 'hq', '-b:v', '3M', '-c:a', 'ac3', '-b:a', '196k', '-f', 'mpegts', '-nostats', '-hide_banner', '-loglevel', 'info', 'pipe:stdout']
[2022-05-26 20:51:33,507] NOOB - [ffmpeg] Loaded transcoding configurations file, /mnt/raid/ProgRAID/fHDHR/plugins/fHDHR_plugin_stream_ffmpeg/transcode.json
[2022-05-26 20:51:33,508] NOOB - [ffmpeg] Client requested a active transcode for stream.
[2022-05-26 20:51:33,509] NOOB - [ffmpeg] ffmpeg command: ['/usr/bin/ffmpeg', '-hwaccel', 'cuda', '-deint', '1', '-hwaccel_output_format', 'cuda', '-i', '/dev/ceton/ctn91xx_mpeg0_1', '-reconnect', '1', '-reconnect_at_eof', '1', '-reconnect_streamed', '1', '-reconnect_delay_max', '2', '-vf', 'scale_cuda=1920:1080', '-c:v', 'hevc_nvenc', '-preset', 'p6', '-tune', 'hq', '-b:v', '3M', '-c:a', 'ac3', '-b:a', '196k', '-f', 'mpegts', '-nostats', '-hide_banner', '-loglevel', 'info', 'pipe:stdout']
[2022-05-26 20:51:33,579] NOOB - [ffmpeg] Loaded transcoding configurations file, /mnt/raid/ProgRAID/fHDHR/plugins/fHDHR_plugin_stream_ffmpeg/transcode.json
[2022-05-26 20:51:33,580] NOOB - [ffmpeg] Client requested a active transcode for stream.
[2022-05-26 20:51:33,580] NOOB - [ffmpeg] ffmpeg command: ['/usr/bin/ffmpeg', '-hwaccel', 'cuda', '-deint', '1', '-hwaccel_output_format', 'cuda', '-i', '/dev/ceton/ctn91xx_mpeg0_1', '-reconnect', '1', '-reconnect_at_eof', '1', '-reconnect_streamed', '1', '-reconnect_delay_max', '2', '-vf', 'scale_cuda=1920:1080', '-c:v', 'hevc_nvenc', '-preset', 'p6', '-tune', 'hq', '-b:v', '3M', '-c:a', 'ac3', '-b:a', '196k', '-f', 'mpegts', '-nostats', '-hide_banner', '-loglevel', 'info', 'pipe:stdout']
[2022-05-26 20:51:33,652] NOOB - [ffmpeg] Loaded transcoding configurations file, /mnt/raid/ProgRAID/fHDHR/plugins/fHDHR_plugin_stream_ffmpeg/transcode.json

Will keep going through it!

I wonder if the 'stream_retry_attempts' can be a clue.  I see two possibilities, we are not returning a failure in get_stream properly so the code is retrying when it does not need to, or we are but the retry logic is not ceton 'friendly'.  That assumes that stream_retry_attempts works as expected on other sources.
The 2nd log is interesting.  It has a pattern 1ms,2ms,3ms,70ms,1ms,2ms,3ms,70ms and so on.  Will need to look through the code again, but I would not expect that bit of code to be inside any kind of look.

Will dig here as well! Almost seems like a race condition, but I may be wrong. It's why I also detect a connection as "External" (I think 😆) ... seems like there may need to be a wait / check for the tuner state to properly change before proceeding forward?
Thanks!

Well, interestingly enough - I am trying to create a test module => runs ffmpeg as a client, streaming directly from fHDHR / Ceton (e.g. http://<IP_ADDRESS>:5006/api/tuners?method=stream&channel=593&origin=ceton), to be able to debug (i.e. automated start and stop of streams, random timing). I am getting it going, and quite quickly created a soft lockup ... LOL. A bunch of shell messages like,
 kernel:[23568.826764] watchdog: BUG: soft lockup - CPU#6 stuck for 250s! [ffmpeg:316493]

And yep - that process number is ffmpeg (from fHDHR),
0 S root      316493       1 99  80   0 - 587238 -     42804   6 19:47 ?        00:04:23 /usr/bin/ffmpeg -hwaccel cuda -deint 1 -hwaccel_output_format cuda -i /dev/ceton/ctn91xx_mpeg0_1 -reconnect 1 -reconnect_at_eof 1 -reconnect_streamed 1 -reconnect_delay_max 2 -vf scale_cuda=1920:1080 -c:v hevc_nvenc -preset p6 -tune hq -b:v 3M -c:a ac3 -b:a 196k -f mpegts -nostats -hide_banner -loglevel info pipe:stdout

But - I couldn't even stop (kill) ffmpeg! To me that seems odd - but it does seem that this instance of ffmpeg is what is getting stuck. Any thoughts? I had to reboot the entire machine, no fix it seems?
Thanks!

Were you logging the duration time between the start and stop?  How were you stopping the process?  Part of me thinks this happens when a terminate is sent too soon after start-up, but I have no details to back that up.
I also came across this bit that seems to make sense, that passing a quit command to the ffmpeg and allow it to exit might make sense.  https://github.com/kkroening/ffmpeg-python/issues/162

Were you logging the duration time between the start and stop? How were you stopping the process? Part of me thinks this happens when a terminate is sent too soon after start-up, but I have no details to back that up.

So funny - I say that because I was starting to think timing is driving this also. But not necessarily time from start to stop, but rather multiple starts too close to each other. I say that because when I run my scheduler / test routine with one job (tuner), no issue. But if I start a couple at the same time ... boom. Or at least I think so 😜. Let me test more, get back to you!

I also came across this bit that seems to make sense, that passing a quit command to the ffmpeg and allow it to exit might make sense

I like it! But how to pass q to a running process? Thanks!

I am fairly certain we are spawning ffmpeg as a process, so this seems like it could fit-
process.communicate(str.encode("q")) #Equivalent to send a Q

That makes sense, but fHDHR seems to be non-responsive once this happens => trying to find another way to kill ffmpeg 😞.
Let me see if I can make it happen more reliably, then it's easier to debug.

So this would be hard to confirm, but how do we know that the process is not responsive until we try to stop it?  Once we have a stuck ffmpeg, it is well and truly stuck.  I have not found anyway to kill it short of a reboot.

So this would be hard to confirm, but how do we know that the process is not responsive until we try to stop it?

Good question ... LOL. FYI, I am running fHDHR as a service => when things go south (soft lockup), then killing the service takes a LOOONG time (if it works at all), and it doesn't kill ffmpeg. I tried to manually kill (kill -9) ffmpeg ... no luck, and after a period of time, the full (Linux) OS hangs.

So this would be hard to confirm, but how do we know that the process is not responsive until we try to stop it? Once we have a stuck ffmpeg, it is well and truly stuck. I have not found anyway to kill it short of a reboot.

Same here! That's the issue. And - I think I may have found how to trigger it (still not 100% sure, but perhaps try it there also?). Start at the "same" time ... two clients (ffmpeg, VLC, whatever). Then I get the pattern like above (point 2). Make sense?
Thanks!

A race condition seems possible-

We fire multiple get_streams and make the API calls to start the tuners, overwhelming the tuner, not likely, but possible.  Could mitigate this by submitting API calls to a thread to serialize them and insert a brief pause between then.
We are starting the ffmpeg process too soon in some cases against a tuner that is not feeding the hardware interface.  Not sure how sensitive ffmpeg would be to not receiving input, this one also seems unlikely.  In the outside chance this is happening again a brief pause in get stream before returning the streamurl to the core

And to ask my 'how do you know question' another way.  I have only see the soft-lockup AFTER trying to stop the process inside of fHDHR by clicking a close button.  I had an orphaned ffmpeg process, but it's state appeared normal before trying to stop it.  So if you launch a bunch of sessions as fast as possible, do you see one or more go into soft-lockup, or is it only when you try to stop one of those sessions?  In my case I think one of the beta Emby releases was retrying to tune too aggressively, as I have not re-encounterd this issue recently, and my only change has been to update as each beta server version is released...

Yep, all makes sense. Pulling my hair out here - it seems I can make this happen somewhat consistently (sadly ... LOL!). And my "External" issue may be similar. Let me try to explain.

Ran a case, single tuner, just monitoring the state of the tuner. The output from some debug I added, below,

[2022-06-10 21:23:09,880] NOOB - [ceton][get_channel_stream:305] get_channel_stream ...
> stream_args: {"channel": "505", "channel_name": "KXAS NBC HD", "channel_callsign": "KXAS NBC HD", "origin_name": "ceton", "method": "ffmpeg", "duration": 0, "transcode_quality": "active", "tuner_number": null, "accessed": "http://<IP_ADDRESS>:5006/api/tuners?method=stream&channel=505&origin=ceton", "base_url": "http://<IP_ADDRESS>:5006", "client": "<IP_ADDRESS>", "client_id": "bf6c3da8-76c5-48c0-bb42-2c727483458d", "origin_quality": null, "bytes_per_read": 1152000, "buffer_size": 3, "stream_restore_attempts": 3}
[2022-06-10 21:23:10,422] NOOB - [ceton][get_ceton_tuner_status:156] Inactive, not scan. Called from [get_channel_stream:306][/mnt/raid/ProgRAID/fHDHR/plugins/fHDHR_plugin_origin_ceton/origin/__init__.py]
[2022-06-10 21:23:10,423] NOOB - [ceton][get_ceton_tuner_status:159] Selected Ceton tuner#: 0
[2022-06-10 21:23:10,424] NOOB - [ceton][get_ceton_tuner_status:168] > scan: False
[2022-06-10 21:23:10,424] NOOB - [ceton][get_ceton_tuner_status:169] > hwinuse: 0
[2022-06-10 21:23:10,425] NOOB - [ceton][get_ceton_tuner_status:170] > transport: STOPPED
[2022-06-10 21:23:10,426] NOOB - [ceton][get_ceton_tuner_status:171] > status: Inactive
[2022-06-10 21:23:10,427] NOOB - [ceton][get_ceton_tuner_status:172] > ceton_pcie: True
[2022-06-10 21:23:10,427] NOOB - [ceton][startstop_ceton_tuner:200] Ceton tuner 0 to be started
[2022-06-10 21:23:10,428] NOOB - [ceton][startstop_ceton_tuner:201] Setting tuner status to "Active"
[2022-06-10 21:23:10,519] NOOB - [ceton][get_channel_stream:312] > port: 8000
[2022-06-10 21:23:10,520] NOOB - [ceton][get_channel_stream:313] > status: Inactive
[2022-06-10 21:23:10,731] NOOB - [ceton][get_channel_stream:320] Preparing Ceton tuner 0 on port: 8000
[2022-06-10 21:23:11,029] NOOB - [ceton][get_channel_stream:334] Initiate PCIe direct streaming, channel 505 from Ceton tuner#: 0
[2022-06-10 21:23:11,036] NOOB - [ffmpeg][get:81] Loaded transcoding configurations file, /mnt/raid/ProgRAID/fHDHR/plugins/fHDHR_plugin_stream_ffmpeg/transcode.json
[2022-06-10 21:23:11,036] NOOB - [ffmpeg][ffmpeg_command_assemble:113] Client requested a active transcode for stream.
[2022-06-10 21:23:11,037] NOOB - [ffmpeg][get:88] ffmpeg command: ['/usr/bin/ffmpeg', '-hwaccel', 'cuda', '-deint', '1', '-hwaccel_output_format', 'cuda', '-i', '/dev/ceton/ctn91xx_mpeg0_0', '-reconnect', '1', '-reconnect_at_eof', '1', '-reconnect_streamed', '1', '-reconnect_delay_max', '2', '-vf', 'scale_cuda=1920:1080', '-c:v', 'hevc_nvenc', '-preset', 'p6', '-tune', 'hq', '-b:v', '3M', '-c:a', 'ac3', '-b:a', '196k', '-f', 'mpegts', '-nostats', '-hide_banner', '-loglevel', 'info', 'pipe:stdout']
[2022-06-10 21:23:13,154] NOOB - [ceton][get_ceton_tuner_status:176] Not Inactive. Called from [get:26][/mnt/raid/ProgRAID/fHDHR/plugins/fHDHR_plugin_origin_ceton/web/ceton_api.py]
[2022-06-10 21:23:13,155] NOOB - [ceton][get_ceton_tuner_status:179] > instance: 0
[2022-06-10 21:23:13,156] NOOB - [ceton][get_ceton_tuner_status:180] > scan: True
[2022-06-10 21:23:13,156] NOOB - [ceton][get_ceton_tuner_status:181] > hwinuse: 1
[2022-06-10 21:23:13,157] NOOB - [ceton][get_ceton_tuner_status:182] > transport: PLAYING
[2022-06-10 21:23:13,158] NOOB - [ceton][get_ceton_tuner_status:183] > status: Inactive
[2022-06-10 21:23:13,158] NOOB - [ceton][get_ceton_tuner_status:184] > ceton_pcie: True

What is really screwy here - these two lines (extracted out),
[2022-06-10 21:23:10,428] NOOB - [ceton][startstop_ceton_tuner:201] Setting tuner status to "Active"
[2022-06-10 21:23:10,520] NOOB - [ceton][get_channel_stream:313] > status: Inactive

I set the value of status to Active, then print it out right after ... and it's Inactive. Huh? It's like there is a delay setting the value?!?!
2. Similar, I then ran my test program, starting 2 clients right after each other (almost the same time, but can't be of course). This is the log output - sorry, it's a pic ... this cause a soft lockup, couldn't copy and paste the text any more. Grabbed this before the view crashed (I had to reboot, the machine locked up)

Interestingly, both requests are being assigned to the same tuner - that can't be good. LOL! Will keep digging, but I think this may be the issue.
Thoughts?
Thanks!

And we have a winner.  I had no evidence to prove it, but your logging shows what I thought would happen.  Two or more requests hit at almost the same time, close enough that the 1st has not gotten far enough along to mark the tuner active and unavailable, the second starts grabbing it.  Now I would normally say the worst we would see is the 2nd client sets the channel and the 1st does not get what they asked for.
But we saw that FFMPEG reading from a device can be blocking, so if both ffmpeg processes are launched against the same hardware device, one may well be starved and never get to the point that it can be killed.
We might be able to set a tuner to a new state 'PENDING' as soon as a request to tune comes in, I mean like the very first step, that way a second request looking for INACTIVE will move on to the next tuner.  If any easy code change like that does not work, we will need to look into what we can do in Python with locking and other methods to ensure that data structures can only be read/updated by one process at a time.
Good job on the debugging effort...

Yes, what you say makes sense - and was thinking something similar. Of course with multiple clients, we can (and will) hit the (test) case above, and also I'm not fully convinced that Plex doesn't rapidly do this when changing channels (no proof ... yet, LOL. Just looking at logs it seems it may be the case).
But to your comments, my worry is 1. above. It seems like Python is slow to set a variable ... I set it, then read it just after - and it's still the old value? That worries me in terms of using some sort of lockout mechanism. More to noodle on there.
Thanks!

This might be even easier.  In get_ceton_tuner_status we check for transport and hwinuse.  We could also check for status 'Inactive', and mark the status as 'Pending' there.  That might, and I mean might be enough to have the 2nd client move to the next tuner.  As it stands we appear to be using status for logging and the UI and not for choosing which tuner to select.  I think if we have two requests that hit very close the exact same time this might still trigger, but I think using a transitional state and checking it might narrow the window.  If it does not we'd need to add a lock as the only way to ensure that only one process can search/update the tunerstatus dict at a time...

What you say makes sense, and I think this may be relatively easy to do (fingers crossed ... 😆). But - to get there, I need to figure this out - and it's wracking (and wrecking) my brain. Let me try to explain.
Some info from the logs (and some debug info I have added to get to the bottom of this),
[2022-06-11 09:46:36,321] NOOB - [ceton][get_channel_stream:304] get_channel_stream ...
> stream_args: {"channel": "505", "channel_name": "KXAS NBC HD", "channel_callsign": "KXAS NBC HD", "origin_name": "ceton", "method": "ffmpeg", "duration": 0, "transcode_quality": "active", "tuner_number": null, "accessed": "http://<IP_ADDRESS>:5006/api/tuners?method=stream&channel=505&origin=ceton", "base_url": "http://<IP_ADDRESS>:5006", "client": "<IP_ADDRESS>", "client_id": "b2e3a03a-3b3f-4ed2-b2dc-1a1a8a7b06ad", "origin_quality": null, "bytes_per_read": 1152000, "buffer_size": 3, "stream_restore_attempts": 3}
[2022-06-11 09:46:36,627] NOOB - [ceton][get_ceton_tuner_status:156] Inactive, not scan. Called from [get_channel_stream:305][/mnt/raid/ProgRAID/fHDHR/plugins/fHDHR_plugin_origin_ceton/origin/__init__.py]
[2022-06-11 09:46:36,627] NOOB - [ceton][get_ceton_tuner_status:159] Selected Ceton tuner#: 0
[2022-06-11 09:46:36,628] NOOB - [ceton][get_ceton_tuner_status:168] > scan: False, hwinuse: 0, transport: STOPPED, status: Inactive, ceton_pcie: True
[2022-06-11 09:46:36,628] NOOB - [ceton][startstop_ceton_tuner:198] Ceton tuner 0 to be started
[2022-06-11 09:46:36,628] NOOB - [ceton][startstop_ceton_tuner:199] Setting tuner status to "Active"
[2022-06-11 09:46:36,628] NOOB - [ceton][startstop_ceton_tuner:201] Checking, status: tuner 0, status Active
[2022-06-11 09:46:36,786] NOOB - [ceton][get_channel_stream:311] > port: 8000
[2022-06-11 09:46:36,787] NOOB - [ceton][get_channel_stream:312] > tuner: 0
[2022-06-11 09:46:36,788] NOOB - [ceton][get_channel_stream:313] > status: Active
[2022-06-11 09:46:36,949] NOOB - [ceton][get_channel_stream:320] Preparing Ceton tuner 0 on port: 8000
[2022-06-11 09:46:37,313] NOOB - [ceton][get_channel_stream:334] Initiate PCIe direct streaming, channel 505 from Ceton tuner#: 0
[2022-06-11 09:46:37,318] NOOB - [ffmpeg][get:81] Loaded transcoding configurations file, /mnt/raid/ProgRAID/fHDHR/plugins/fHDHR_plugin_stream_ffmpeg/transcode.json
[2022-06-11 09:46:37,319] NOOB - [ffmpeg][ffmpeg_command_assemble:113] Client requested a active transcode for stream.
[2022-06-11 09:46:37,319] NOOB - [ffmpeg][get:88] ffmpeg command: ['/usr/bin/ffmpeg', '-hwaccel', 'cuda', '-deint', '1', '-hwaccel_output_format', 'cuda', '-i', '/dev/ceton/ctn91xx_mpeg0_0', '-reconnect', '1', '-reconnect_at_eof', '1', '-reconnect_streamed', '1', '-reconnect_delay_max', '2', '-vf', 'scale_cuda=1920:1080', '-c:v', 'hevc_nvenc', '-preset', 'p6', '-tune', 'hq', '-b:v', '3M', '-c:a', 'ac3', '-b:a', '196k', '-f', 'mpegts', '-nostats', '-hide_banner', '-loglevel', 'info', 'pipe:stdout']
[2022-06-11 09:46:39,587] NOOB - [ceton][get_ceton_tuner_status:175] Not Inactive. Called from [get:26][/mnt/raid/ProgRAID/fHDHR/plugins/fHDHR_plugin_origin_ceton/web/ceton_api.py]
[2022-06-11 09:46:39,588] NOOB - [ceton][get_ceton_tuner_status:178] > instance: 0, scan: True, hwinuse: 1, transport: PLAYING, status: Inactive, ceton_pcie: True
[2022-06-11 09:46:39,588] NOOB - [ceton][get_ceton_tuner_status:184] Not Active. Called from [get:26][/mnt/raid/ProgRAID/fHDHR/plugins/fHDHR_plugin_origin_ceton/web/ceton_api.py]
[2022-06-11 09:46:39,589] NOOB - [ceton][get_ceton_tuner_status:187] Ceton tuner, status "fail": Instance = 0, Status = Inactive

A request comes in (that I have initiated), through get_channel_stream, and this in turn calls get_ceton_tuner_status - all makes sense so far. It finds that tuner #0 is available (that's correct), and startstop_ceton_tuner is called - also correct. In startstop_ceton_tuner, the status is set, through self.tunerstatus[str(instance)]['status'] = "Active". I added a line right here to check, and yep ... Checking, status: tuner 0, status Active => all OK. And, back in get_channel_stream, yep, still OK ... > status: Active. But then it gets weird 😜. The API (from a call I have) checks the status, in get_ceton_tuner_status, but now status: Inactive. Huh?!?! Need to figure this out, then I can use Active and Inactive for dealing with the issue above - but first need them to be reliable.
Any suggestions welcome!
Thanks!

I found a few good articles on thread-safe dict access.   The app is using threads with Flask, and so it is possible there is a context switch and the 2nd tread reads the status before it is updated, but then context switches back to the 1st thread before logging.
The more digging I did, the more convinced we'll need to have a mutex lock around updates to status.  We should not need it for reads, only updates.

That makes sense - though I have never used them before 🤣. Hoping you have!
If we can count on the status being reliable, I do think we can use it in a pretty easy way to handle the dual request issue.
Thanks!

BTW, just yell if you want my test code. One small (minor) item in it I'm still working on, but in general it lets you trigger the issue.

I have not had a hung session in awhile, so best I can do is confirm it does not break something...
On the subject of locking, I have read about it in various projects out of general interest, and while I get the concept, I also have never implemented a solution using it.  I may see if I can code something up in the next few days...

Or - another thought on this. In parallel, I'll try to make use of the scan argument (passed to get_ceton_tuner_status). If this is only a scan (like the API uses), then don't set / change status - just use it as a check. It will "catch up", and no "harm" is done as it's not changing anything.
Make sense?
Thanks!

OK, you hit the nail on the head! And ... I found a very easy solution 😄. Tested, and works. I did this,
    def get_channel_stream(self, chandict, stream_args):
        self.lock.acquire()
        self.plugin_utils.logger.noob('Locked ...')

=> Basically, as soon as a channel stream is requested ... lock it (first thing). Process this one, and then before returning,
        self.lock.release()
        self.plugin_utils.logger.noob('Unocked.')
        return stream_info

Checked it out, and - yep, it works! The first one is cleanly handled, then unlocks ... and let's the second one proceed. I tested even with 3 starting at the same time, and they sequentially take tuners 0, 1, 2.
Make sense? Seem like a reasonable approach?
Thanks!

Catching up, locks are pretty common in fhdhr, I look forward to a PR

Sweet! Now for the load and traffic volume the app will likely see the location  of the lock will not matter (much), but ideally it would right before the point of contention inside the loop in ceton_get_tuner_status right before changing the state.  But that is such a micro-optimization that it is not worth chasing, and having it that high up in the stack will cover other corner case that we might not have encountered.
I really wish we had a way to get metrics on how many people are using the plugin.  I am aware of three, and I am biased, but this is a really excellent setup at this point, and solving this rare crash is icing on the cake...

Catching up, locks are pretty common in fhdhr, I look forward to a PR

Yep! Need to fix the one other niggling thing that is "ticking" me off ... LOL! It's about the API, and status - but won't let that hold this fix up too much.

But that is such a micro-optimization that it is not worth chasing, and having it that high up in the stack will cover other corner case that we might not have encountered.

Agreed! I'll clean some other things up there, get the PR - and of course you can comment on it (please do!). My thought is the same as yours ... make it robust first, worry about further optimization once we make sure to avoid the "critical" (reboot causing) case.

I really wish we had a way to get metrics on how many people are using the plugin. I am aware of three, and I am biased, but this is a really excellent setup at this point, and solving this rare crash is icing on the cake...

So much agree! And I do have to say, with this 4-tuner card now, it really is an awesome setup. The whole project is awesome as far as I'm concerned. Thanks!

OK, I seem to have this fully working here - PR coming right away. It handles the locking (like we talked about), also logic updates as the state was getting incorrectly set ... that was causing part of my confusion. By all means, check it out and comment. Thanks!

PR #44

Closing this now, PR merged.


Support Laravel 5.6

The Illuminate\Contracts\Logging\Log Interface
This interface has been removed since this interface was a total duplication of the  Psr\Log\LoggerInterface interface. You should type-hint the Psr\Log\LoggerInterface interface instead.

Sorry, duplicate of #288

Thanks for the PR, but actually this won't work in 5.5 or 5.6 because:

This would break dependency resolution for the log contract in 5.5.
The interface is actually not a total copy of the PSR interface - https://github.com/laravel/framework/blob/5.5/src/Illuminate/Contracts/Logging/Log.php#L87 for example.
Supporting Laravel 5.6 needs more work than just this unfortunately, but my other PR should explain things. :)


Stuck at "Save & continue"

Hi,
Thank you so much for this great tool. everything is working for me except that the bot gets stuck at the payment step.
I have my paypal account saved in my nike account and it is automatically selected at checkout.
However the bot fails to click the "save & continue" button then submit order. how can i fix that?
I tried my command with and without --select-payment and/or --purchase
Thanks

New update is coming at some point that should address this. Also, you won’t need to pass “—select-payment” parameter in his case


bug: confirm dialog not showing apply button in node red 0.20.7

see also:
https://community.sw.siemens.com/s/question/0D54O00006eK7pKSAS/error-while-configuring-agent-using-nodered

this seems to be occuring on iot2040 with preinstalled node-red, the issue is under investigation

The issue is reproducable. Even though the node-red 0.20.7 is quite old we will publish a fix to help with this issue as this version is on the IoT 2040.


Make List View Responsive

Make List View Responsive

@SMahil can you get the errors fixed?

PR shows errors :

Both unit and functional tests fail.


Refactors workspace validation

Scope of changes
Removes validation for the workspace on the FE and displays messaging from the BE.
Fixes SC-21267
Type of change

[ ] new feature
[ ] bug fix
[ ] documentation
[ ] testing
[x] technical debt
[ ] other (describe)

Acceptance criteria
https://www.awesomescreenshot.com/video/20870723?key=0563184eab29523952f48d7427fc25ab
Definition of Done

[x] I have manually tested the change running it locally (having rebuilt all containers) or via unit tests
[ ] I have added unit and/or integration tests that cover my changes
[ ] I have added new test fixtures as needed to support added tests
[ ] I have updated the dependencies list if necessary (including updating yarn.lock and/or go.sum)
[ ] I have recompiled and included new protocol buffers to reflect changes I made if necessary
[x] Check this box if a reviewer can merge this pull request after approval (leave it unchecked if you want to do it yourself)
[x] I have notified the reviewer via Shortcut or Slack that this is ready for review
[ ] Front-end: Checked sm, md, lg screen resolutions for effective responsiveness
[ ] Backend-end: Documented service configuration changes or created related devops stories

Reviewer(s) checklist

[ ] Front-end: I've reviewed the Figma design and confirmed that changes match the spec.
[ ] Any new user-facing content that has been added for this PR has been QA'ed to ensure correct grammar, spelling, and understandability.
[ ] Are there any TODOs in this PR that should be turned into stories?

@masskoder Here's a video of how the validation messages appear now: https://www.awesomescreenshot.com/video/20897739?key=6ae5f9332b3f87c8303ef1c54ac1a003


Deploy nodes one by one for safety

Change summary:

Deploy nodes one by one:

BEFORE: file copy for node 0 -> file copy for node 1 -> ... -> file copy for node 4 -> setup for node 0 -> ... -> setup for node 4
AFTER: file copy for node 0 -> setup for node 0 -> file copy for node 1 -> setup for node 1 -> ... -> file copy for node 4 -> setup for node 4

Thanks for the fast review!


jsc: How to output to LibTerm’s console?

Hi,
console.log(), debug() and print() don’t work.
Only alert() works but not very user friendly :-).
Thanks!

jsc prints the result of the script. So for example, 1+1 will print 2. I will anyway add functions to show output.

I tink so


Remove usages of common/diagnostics

There is base/common/diagnostics.ts which isn't used much anymore and also off by default (requires code change to be enabled). This util shouldn't be used anymore as we now have a solid logging story. Please stop using it and delete it then.

@bpasero I have removed the diagnostics.ts and am now instead using logService.info
The only actual change will be in textFileEditorModel so check that out once you have a chance

@isidorn thanks LGTM


Address concurrency issue (Refactor)

This PR refactors the fix made in https://github.com/docker/swarm/pull/2826
After testing the fix in the real world, with over 500 nodes and thousands of active containers, we noticed that any hiccup or delays on one node, can cause the RefreshContainers to slow down and hold the lock while waiting for API calls to return.
This issue can be seen with read only calls, like docker info which iterates through the list of containers but hang trying to acquire the engine lock first while RefreshContainers is running.
A quick test:

on a 3 nodes cluster (1 manager 2 workers)
ssh to a worker node and add latency/throttle the connection on eth0
sudo tc qdisc add dev eth0 root netem delay 5s in my case, I added a ridiculous 5 seconds
Force the RefreshEngines call by running the following against swarm classic
docker ps -f name="^ucp-"
While waiting for the above to return, run docker info and noticed that it's getting blocked while waiting for  docker ps -f name="whatever you set ContainerNameRefreshFilter to" to return (edited)

The new fix remove the locks from API calls and used a clever logic proposed by @wsong to address the original issue in https://github.com/docker/swarm/pull/282

Please sign your commits following these rules:
https://github.com/moby/moby/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "esc-305v2" git@github.com:dani-docker/swarm.git somewhere
$ cd somewhere
$ git rebase -i HEAD~842353489344
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

Worse to mention this in case someone ran into it.
So after opening the lock on the RefreshContainers, during the following stress test.

Ran a test harness that creates 800 containers in 40 concurrent thread.
At the same time, invoked the RefreshContainers by calling for i in {1..500}; do docker ps -f name="whatever your ContainerNameRefreshFilter is set to"; done

I see the below errors.
Those are caused on concurrent deletes that are part of the test harness cleanup, so by the time we call updateContainer the container is getting deleted, hence the error.
It is benign, but worth noting in case it can cause a bigger issue.
time="2018-03-10T04:22:19Z" level=error msg="Unable to update state of container \"de21fada7cf50d6ef9b105a1fafe121c7b616b1d12a2793909a9eaaae7ee5a06\": Error: No such container: de21fada7cf50d6ef9b105a1fafe121c7b616b1d12a2793909a9eaaae7ee5a06" id="XYT3:LNNK:JGPX:RZEH:GJSD:2FE7:LPY2:V753:D2HV:LVEB:BEO2:KSQ6|<IP_ADDRESS>:12376" name=dani-dev-ucp-226-ubuntu-2
time="2018-03-10T04:22:19Z" level=error msg="Unable to update state of container \"96e83ebb72b5ee4c81314fa7ba882065496b4f11bddf512ce425e3fe8c5a6f8f\": Error: No such container: 96e83ebb72b5ee4c81314fa7ba882065496b4f11bddf512ce425e3fe8c5a6f8f" id="XYT3:LNNK:JGPX:RZEH:GJSD:2FE7:LPY2:V753:D2HV:LVEB:BEO2:KSQ6|<IP_ADDRESS>:12376" name=dani-dev-ucp-226-ubuntu-2
time="2018-03-10T04:22:28Z" level=error msg="Unable to update state of container \"83dd1059de40e22ca9dc859b6fbb574712798739ce06b4324ace8719fcafab6b\": Error: No such container: 83dd1059de40e22ca9dc859b6fbb574712798739ce06b4324ace8719fcafab6b" id="Z4ZG:JQDK:CWQM:ZJFO:ILI2:XNKJ:WKTZ:ISZU:VRT2:T2LH:GPK2:RO3D|<IP_ADDRESS>:12376" name=dani-dev-ucp-226-ubuntu-0
time="2018-03-10T04:22:28Z" level=error msg="Unable to update state of container \"3c47618162d54847fcc2edfbda393b1796e36e7c02dc1347776af5e4a6f55352\": Error: No such container: 3c47618162d54847fcc2edfbda393b1796e36e7c02dc1347776af5e4a6f55352" id="Z4ZG:JQDK:CWQM:ZJFO:ILI2:XNKJ:WKTZ:ISZU:VRT2:T2LH:GPK2:RO3D|<IP_ADDRESS>:12376" name=dani-dev-ucp-226-ubuntu-0

@wsong if you can ack the above

Those "Unable to update state" error messages are going to cause a ton of spam in user workloads where they create and delete containers very rapidly.
Perhaps we should check the error message and see if it contains "No such container"; if it does, then we should just ignore the error.
Alternately, if we want to be a little more conservative, when we get a "No such container" error, we could grab the read lock and check e.containers to see if the container ID is still in there; if it's not, we can assume a user deleted the container. If it is still in e.containers but we got a "No such container" error, we can log an error then.

Just to be clear the "Unable to update state"  is not a result of the initial changes made in this PR.
I agree, I will implement the "conservative" approach and checking e.containers before eating the exception/err, you ok if we handle it in a separate PR so we can differentiate the 2 issues?

I think it would make more sense in this PR, if it's easy to add.

ok, adding it now and running some test

@wsong
Fixed the noisy error message and pushed it in its own commit, so it can be easily reviewed.
If a squash is needed for merge, please let me know.

done and verified the latest changes

@wsong : just spoke to @dani-docker and he feels PR is ready to be merged. Is there something else pending? I am trying to make a determination if this can be included in 2.2.8. wdyt?
cc @dani-docker @marcusmartins


Fix coveralls

Resolves #8

Changes Unknown when pulling 0554af2e6e383493383492ab2d448fb15408684c on bug/fix-coveralls into ** on master**.

Changes Unknown when pulling 1341494d3f897c9df65baac0813a7c3e8ae0e517 on bug/fix-coveralls into ** on master**.

Changes Unknown when pulling a737dbfcfa359d74afb4159a9316999742255b97 on bug/fix-coveralls into ** on master**.


Template reference variables lost

Template reference variables are lost when a responsive directive is added. For example:
<input #phone placeholder="phone number" *xs>
In this case, referencing the 'phone' variable in other parts of the template yields an exception.

hum.... I'll see if I found a solution to this. ; )

Try with:
<template [xs]><input #phone placeholder="phone number"></template>

And tell me if that work. ; )


Create Maintainer List

Possibly included in Owners document.

Add to aggregated maintainer list.

Closed by #37


Separate local and saucelabs tests

Changes:

Separate local tests from remote tests
Learna will handle all local tests but not remote tests. A dev and run npm run test at the top level and it will execute all packages except the test package
Remote tests (liek saucelabs) will run tests in the tests package.
Create tunnels in saucelabs based on the commits git SHA.

Expected Results:
Reduced proxy connection requests
Currently a 'proxy' connection is created for every package in every environment per github action (ie: labs react runs Dev and Prod on push and pull_requests, so it creates 4 proxy connections). Results in 4 proxy connections per package per PR.
When we isolate remote tests to the tests package, only 4 proxy connections are made per PR.
Run remote tests sequentially
Safari and IE have a difficult time finishing their last few tests unless they are run 1 at a time. Setting CONCURRENT_FRAMES to 1 greatly reduces failures locally and extenally.
Reduced number of tunnels
Using the sharedTunnel and tunnelIdentifier config options in our saucelabs launcher, we can provide a  tunnel with high-availability. The tunnel ID is based on the commit's github SHA value. There is one tunnel provided for all github actions in a PR.
Isolate remote tests
The tests package will maintain a list of all tests that must be run on external machines / browsers. This list should be kept as minimal and flat as possible.
Trinity browsers consistently pass
I believe that when we isolate tests to one "high capacity" tunnel per PR request, we get a better pass rate. The trinity browsers very rarely fail with this configuration
Shorter test times
Sauce tests will run on average between 10-13 mins with this setup (That's a big win). This is faster than our benchmarks tests.
if IE passes, it happens around 20mins because we ask IE tests to run twice if it fails the first time.
Speed issues are most likely due to what github actions are, shared linux instances, probably similar to KVM but for azure.
Expected Failures:
IE will most likely continue to fail
The only consistent failure in this setup is still IE. the duration of our tests. We run 50+ test files which are most likely run inside iframes. This might be too long for github actions.
Comparatively, material-web uses karma. karma bundles all tests and then runs them, this would be closer to running 1 test file.
This might be the only difference between passing and failing for IE. Saucelabs IE tests can be run locally and will pass. The same tests run in github actions prove to be brittle.
Followup Changes

Research Github action instances, most likely docker / kubernetes. How dynamic is their IP? could that be what generates unexpected failures and disconnects?

Confirm a shared tunnel is working out for the teammates. There's a possibility this is an adjacent fix, a good start but not a complete solution

Reduce the coverage of IE. Explore reducing the amount of tests for IE to handle. Maybe only core libraries and polyfill tests. Do we say that everything will work in IE or only guarantee core features?

Separate local and remote configs for web test runner

It seems like there's ongoing experimentation happening in this PR, which makes me a little unsure about when/how to review. But there are already some great improvements that it feels like we could be landing!
What do you think about splitting this PR apart into some more narrowly scoped PRs, and landing them incrementally, and then continuing with experimentation to get IE passing in a separate non-PR-associated branch? It would be cool to land incremental improvements, even if we don't get IE to pass right away, and would help with reviewing too, since there would be less to try and understand all at once.
Some ideas for some more narrowly scoped PRs:

The new SAUCE_TUNNEL_ID improvements
Fixing the issue where we were running more tests than necessary in the sauce job
Adding missing tests
Re-organization of config files
Updated docs

@aomarks sounds good to me!
Long as the reviews for the smaller PRs get done during my spring I don't have a problem with smaller PRs.
These last few pushes were me checking what breaks and doesn't in our sauce configs, I have to push it to GitHub in order to view. Everything passes locallt

I'm going to upload a few more changes and then freeze this PR for review.
I'll also leave details about what sepcifically these changes do, and what I'm aiming for, and what plans for the future are.

making this a draft so i can isolate what tests consistently pass on saucelabs

keeping this in a draft phase and hopefully will parse these out into separate tasks
There is a core chunk of work: decrease sauce tunnels
Dx could be improved: recursion in a config

I'll be breaking this into separate PRs:
But before I do, I'd like to point out that everything passes with this current setup
1 tunnel
4 "proxies" / "connections" to the 1 tunnel (ie dev, ie prod, sauce dev, sauce prod)
The caveat is that only lit-html tests provable run successfully. I cannot confirm other tests pass consistently. But with this setup I can confirm our tests will run in all browsers in saucelabs and locally only running lit-html
Which tells me our tests are failing or are flakey. I hope this is not the case but this is the conclusion I have after working on this for a month. We have failing tests. We need to identify which ones fail or flake. It is currently very obtuse to find that out.
The purpose of this effort is to give better fails, allowing us to unbreak ourselves.
But I'd like future reviewers to keep in mind, despite how much we reduce complexity or despite how confident we feel our tests are successful that we should let the actual tests tell us if they should pass or fail rather than our confidence. We might not have "all green" to start adding changes. We need to be okay with this <3
It'll get better, is my main takeaway

I can confir that lit-html and reactive-element tests will pass
onwards

lit-element consitently proves itself to 'hang' and cause other tests to timeout and fail.
removing and moving on.

separating browsers got all checkmarks ;_;

"With this setup, we strongly recommend applying a --tunnel-identifier, which will make it easier for tracking tunnels. Otherwise, test traffic initiated using your account will use an unnamed tunnel automatically."
https://docs.saucelabs.com/secure-connections/sauce-connect/setup-configuration/high-availability/
main might all be running on the same tunnel if we do not identify one

removing lit-element tests and running jobs per browser give consistent and clear successes.
will try with dev and prod mode smushed together tomorrow.
differences from main:

run dev and prod modes separate
unique identifiers for build based on gitaction+gitsha+mode
shared tunnel per commit


Postgres array escaping in where clause broken in 0.12

So, I just updated from 0.11.10 to 0.12.2, and it broke one of my queries. I've confirmed that this occurs on 0.12.0 and 0.12.1 as well.
This used to work:
query.where('array_field', '&&', [7]);

0.11.10 output: (working)
WHERE "array_field" && '{"7"}'

0.12.2 output: (not working)
WHERE "array_field" && {7}

My workaround for now is:
query.whereRaw(`"array_field" && '?'`, [[7]]);

Should be fixed in 0.12.3


Don't forget to start SQL Agent again after step 12

It may be worth adding a Note section to remind users who stopped the SQL agent earlier in the process to start it again. Otherwise Agent jobs such as backups/maintenance won't run.

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

ID: d41367fc-38cf-0c73-3ea8-93bff726f421
Version Independent ID: 07b2d0b3-2013-a133-9d1e-ee2d249740d5
Content: Connect to SQL Server When System Administrators Are Locked Out - SQL Server
Content Source: docs/database-engine/configure-windows/connect-to-sql-server-when-system-administrators-are-locked-out.md
Product: sql
Technology: configuration
GitHub Login: @MikeRayMSFT
Microsoft Alias: mikeray

@t0mmg  Thank you for the feedback.
The documentation has been updated and is pending review.


Check result UI

Resolves #316
@dariober, I've moved your commits into this branch so I could merge the previous commits to the other branch.

@dariober, I added a change to this branch so that you can now pass a URL parameter to the checks endpoint to get only the checks for a particular assembly, e.g. http://localhost:3999/checks?assembly=652605cb511eaaf0e510ce89.
Could you update the table so that it only fetches checks for the selected assembly, and then re-fetches new results when the assembly is changed?


Dashboard - 404 thrown in dashboard latest on Rancher master

Rancher version: master-head (07/15/2020) fd3826a19
dashboard-index -> latest

Failed to load resource: the server responded with a status of 404 ()
index.js:245 Loading error Error
    at y.setError (index.js:243)
    at vuex.esm.js:840
    at vuex.esm.js:462
    at Array.forEach (<anonymous>)
    at vuex.esm.js:461
    at y._withCommit (vuex.esm.js:620)
    at y.commit (vuex.esm.js:460)
    at y.commit (vuex.esm.js:405)
    at authenticated.js:127
    at d (runtime.js:45)

@izaac Presumably this doesn't happen anymore..

Yes, this is no longer happening in Rancher version master-head (07/31/2020) 69bdef3ea


plate file cannot be opened by OpenSCAD

lightcycle plate file generated by website cannot be opened by OpenSCAD.

all keyboard parameters is default.

Every time open the plate file, the OpenSCAD will be not responding.

but the case file is ok.

The lightcycle scad file contains much more code than manuform. You can compare the scad file size. So just wait, don't force quit.


Format of ids for GAOntologyTerm

Current docs state:
  /**
  The ID defined by the external onotology source.
  (e.g. `http://purl.obolibrary.org/obo/OBI_0001271`)
  */
  string id;

This is fairly open ended and we can imagine confusion and inconsistent usage here.
For the ontologies currently referenced in the metadata schema, e.g.

HP
UBERON
CL
OBI

Terms are typically referenced in two ways.
URIs/IRIs
For many biological ontologies these are typically obolibrary purls, which follow:
http://purl.obolibrary.org/obo/<IDSPACE>_<NUMERICFRAGMENT>

See: http://www.obofoundry.org/id-policy.shtml
OBO-Style identifiers
Typically follow the form
<IDSPACE>:<NUMERICFRAGMENT>

Options

The schema should mandate URIs only (using the URI form recommended by the source ontology)
The schema should mandate OBO-Style IDs
The schema should have separate 'id' and 'iri' fields
The schema should have a flexible field

Option 1 is probably the conceptually simplest. Option 2 is not very future proof as it doesn't allow open-ended expansion to any ontology out there on the semantic web. Option 3 is probably overkill.
I would advocate option 4. To elaborate, we allow the field to contain either a URI or a CURIE (https://en.wikipedia.org/wiki/CURIE see also http://www.w3.org/TR/curie/), without the brackets. We then assume the existence of a number of implicit qname prefixes. E.g.
@prefix UBERON http://purl.obolibrary.org/obo/UBERON_
@prefix CL http://purl.obolibrary.org/obo/CL_
@prefix OBI http://purl.obolibrary.org/obo/OBI_
@prefix NCBITaxon http://purl.obolibrary.org/obo/NCBITaxon_

This could potentially live in a separate JSON-LD context file.
This is also consistent with the translation in the OBO-Format spec: http://oboformat.googlecode.com/svn/trunk/doc/obo-syntax.html#5.9.1
I would be happy to branch and make a pull request, but I thought it worthwhile polling for opinions. Need this to be future-proof, consistent - but also not over-engineered.

The MME is hoping to converge on a compatible representation. Curious if there are any updates?

Not sure if there are updates from other WGs, but I think MME should continue to use CURIEs of the form HP:nnnnnnn, these are at least compatible with what major databases are using, and will the semweb stack (assuming default prefix declarations)

Okay, thanks. Will do.

IMHO specific implementations may define their more restrictive use of specific formats, e.g. it is fine for MME to restrict to CURIEs. In the general context, we can not restrict to use only specific ontologies.

I agree, we should not restrict to specific ontologies, though we can certainly recommend and test using a given set. Ideally we can stick to CURIEs and standardize prefixs as we see lots of messes where this has not been done.

CURIEs with standardized prefixes (as @mellybelly suggested) appear to be a viale solution for MME groups right now. Using JSON-LD sounds interesting though. Maybe this could be an optional part / use as part of the GA4GH schemas.

This has been dormant since January. I'm closing this in 2 days unless there are objections.

It's still not resolved.
https://github.com/ga4gh/schemas/blob/master/src/main/resources/avro/ontologies.avdl
still calls the OBI URI an id. Unless the terminology is resolved and a standard way of identifying ontology classes is specified everyone will choose a different convention and complex ID processing code will be required to interoperate.

@cmungall Agreed. There was a presentation before the easter break from the team behind the "FAIR data" principles. I was really impressed with their work, and I wonder if they have come up with a way to resolve this issue. I will direct him towards this.

For discussion: split into id and url in https://github.com/ga4gh/metadata-team/blob/master/avro-playground/metadata_redo.avdl

I think there is still the possibility for large confusion here. It mixes the concept of a URL fragment with an ID; there are sometimes but not always the same thing. Also "ID defined by external ontology source" doesn't really mean anything in a lot of cases. OBI do not define IDs anywhere. Their currency is URIs.
There is nothing here to prevent the scenario where people refer to the same OBI class as

OBI_0001271
OBO:OBI_0001271
OBI:0001271

Where is the authoritative list of CURIEs

Define authoritative? Several large and equally reputable groups use different formats.

Precisely. Is there one which will work well? If we can't refer to a set of these is it practical to use CURIEs - I am not against this, seems like the next obvious question.

It's difficult for sure. I know EBI are currently working on the next itteration of their ontology lookup service. As part of this, the data is searchable. For HPO, the term IDs are for example "hpo:http://purl.obolibrary.org/obo/HP_0200117". They also store an "id_annotation" as "HP:0200117", but also a list of "short_form" terms, which includes "HP_0200117".
As far as very useful sources of data, EBI comes up pretty near the top. They've been looking at this, and it looks like the result is there's no concensus. Currently, you need to use the format HP:0200117 to find the term by ID, but the current system is old, and a large update is coming.

I'm increasingly thinking we need an Ontology task team / working group (possibly as a sub of the DWG). /cc @ga4gh/global-alliance-contributors

this could be the perfect connector to ELIXR
Barend Mons
sent from a mobile device
<EMAIL_ADDRESS><EMAIL_ADDRESS>
On May 22, 2015, at 14:32, Ben Hutton<EMAIL_ADDRESS>wrote:
I'm increasingly thinking we need an Ontology task team / working group (possibly as a sub of the DWG). /cc @ga4gh/global-alliance-contributors
—
Reply to this email directly or view it on GitHub.

Hi Ben,
You have echoed a couple of recent conversations from other groups. This is a subject that covers so many different areas of work and is a real restriction on progress. There is a dedicated meeting at Leiden (on 9th June) to discuss it and I wouldn’t be surprised to see a new task team come out of that.
Cheers
David

On May 22, 2015, at 1:32 PM, Ben Hutton<EMAIL_ADDRESS>wrote:
I'm increasingly thinking we need an Ontology task team / working group (possibly as a sub of the DWG). /cc @ga4gh/global-alliance-contributors https://github.com/orgs/ga4gh/teams/global-alliance-contributors
—
Reply to this email directly or view it on GitHub https://github.com/ga4gh/schemas/issues/165#issuecomment-104648869.

Ben - Happy that you find my group's resources useful and yes we are rewriting OLS. I am not convinced that splitting the ontology effort further is desirable - meta data has a large group of ontologists included already. More ontologists is not always a good thing.

@helenp Sure! I'm not nessecerally suggesting more people are involved, but more specifically that it's made clear to everyone that the issues around ontologies is being looked at. Something like defining a list of CURIEs or a method of ontology term identification, that's then pushed out to all the working groups, would be hugely benificial. I felt that formalising the work on ontologies would also allow the other working groups to know where to go to get answers / spear discussion about topics, and have clear document products as a result.
@D-lloyd I saw this on the agenda. I don't know what time has been allocated within that section, but I think it's key to discuss / hear what's happening with the OLS rewrite. I'm currently using one of the OLS tools in development to extract an ontology file to Solr for searching. A standardised way of importing data, not only is very benifical to others by making the use of ontologies easier, but also well help inform agreements on which of the multiple term id representations (CURIEs) the Global Alliance should suggest / push for.

I have pointed @simonjupp at this thread (OLS dev) we should be able to do something that helps, Ben come and see us if it helps.

Well, we have an ontologies task team in the CWG already, but I agree that there are technical specifications that need work up that are likely out of scope for the CWG, which is focused more on use cases. We should discuss this in Leiden.
I prefer use of CURIES and it is likely that the GA4GH would want to have a registry of whatever is in use throughout all the schemas. It doesn't have to be about authority (as there are many overlapping "authoritative" sources) but rather what is required by any users/contributors of the GA4GH schemas to share their data. Perhaps we should consider some process by which anyone sharing data via GA4GH can register their CURIES in a shared repo. We'd need some inclusion/exclusion criteria and guidelines for contributors.
There is also work to be done to specify where and when certain ontology sources should or could be used. This is the much harder part ;-).
@nlwashington @kshefchek @cmungall perhaps we can do an example in G2P for how this might work with a diversity of disease and phenotype ontology sources, we are on the way towards that already.

@helenp Already in contact with Simon! Very helpful! Using the java code in the new OLS project to load in ontology data to Solr. Waiting for his return to ask further question on how I can integrate this data! =]
@mellybelly Another repository would most probably add to the confusion. Versioning is a major issue with ontologies! It's already a very messy problem. It looks like the OLS will allow you to look up terms based on multiple formats. Directing people to the new OLS should hopefully be really helpful. I understand it will be updated nightly, but of course one can always fix a versioning and run their own solr install.

@Relequestual - I'll answer in more detail later, but answering your original question and the HP example. In a semantic web toolchain the URI is canonical. For any OBO library ontology, there is an authoritative deterministic way to map this to an identifier in OBO format, which is what is used by all bioinformatics dbs not based on a semweb tool chain, and the id would be HP:0200117.

http://www.obofoundry.org/id-policy.shtml
http://oboformat.googlecode.com/svn/trunk/doc/obo-syntax.html#2.5
http://oboformat.googlecode.com/svn/trunk/doc/obo-syntax.html#5.9

More later...

@Relequestual did not mean to imply a new registry at all, quite the contrary.
You are preaching to the choir wrt versioning, I am all too familiar with that problem.
I don't think the problem here is where to go to look up terms based on different formats or sources, we have plenty of places to do that (OLS, NCBO, Ontobee, NCI metathesaurus, etc.)
Some issues we need to think about are:
a) how to reference an ontology class or property in the avro schemas, taking into account the provenance
b) how to specify the domain or range in any given context, and allowable/useful sources - e.g. as per above comments, we don't want to limit people in their choices of ontologies as there are different needs, but at the same time, we want to limit the misuse of incorrect semantic types (e.g. not equate a variant with a gene, or a phenotype with a disease)
c) how to represent IDs. You can see an example from Monarch where we have a CURIE map in a YAML file:
https://github.com/monarch-initiative/dipper/blob/afd2d11bd6356f37333c5514c8d38071e02f1e58/dipper/curie_map.yaml

@cmungall After thinking about this quite a bit over the past few weeks, I agree with your advocacy of option 4.

I'm not sure this issue was discussed at the GA4GH plenary in Leiden last week. @cmungall Your finding of the obo foundary id policy link is most informative. Unless there's any reason not to, it seems like a good definative method for solving this problem.
Question is, what does the solution look like in terms of updating the schemas?

Ben, we will discuss on the meta data call thursday 18 June.

We had some discussions in Leiden (with @mellybelly, @nlwashington, @diekhans). The current majority opinion is to have "polymorphic" ways to reference ontologies, and also to include a way to reference/use local ontologies (e.g. if no best fit reference is known/found, or for legacy => convert later etc.). Also, for records like "disease" (which has yet to be defined as record type), we found the most sensible way to allow references to multiple ontologies, with one being the primary (doodling here):
  primaryReference ontologyTerm;
  alternativeReferences<array<ontologyTerm>>;

Still, there hasn't been implementation work on the exact format of the ontologyTerm object; everybody is welcome, regarding the notes above ...

@helenp If you could write up and post the meeting notes afterwards here, that would be very helpful.  I'm still waiting for my approval to go through for the GA4GH DWG mailing list.
Thanks,
Paul

@selewis are you attending the call on June 18?
My proposal is as follows:

The field id in the OntologyTerm object ( this one ) be constrained to contain CURIEs (e.g. HP:0001234)
GA4GH endorses a set of CURIE prefixes that are consistent with the standard URIs used for classes in that ontology, e.g. "HP": "http://purl.obolibrary.org/obo/HP_"

Note that (1) cannot be enforced within Avro AFAICT, but it would be trivial to write some kind of checker as an additional layer.
Note that this proposal can be seen as a subset of proposal #311 to use JSON-LD ubiquitously - however, the proposal in this ticket is in no way dependent on GA4GH endorsing JSON-LD in whole or in part.
For (2), the CURIE map could live within the GA4GH github repository (and sync with external sources), or it could point outwards to an externally maintained set of CURIE prefixes (e.g. this obo context. Note there is no requirement for programmatic consumers or producers of GA4GH json, avro, services to be able to process a prefix map or json-ld file. The prefix map will be primarily a social contract to ensure that the same class is referred to in the same way.
This proposal is neutral w.r.t whether a single ID or multiple IDs are used in an annotation (e.g. the disease scenario, where someone may want to record a NCIt class and a SNOMED class and a DOID class).
Note that some schemas (e.g. MME ) may opt not use the OntologyTerm container and instead use a direct reference to an id field. In this case, I would recommend the same guidelines are followed.
This proposal does not explicitly address versioning, but is compatible with a number of different schemes. As a strawman:
record OntologyTerm {
    /**
    A prefixed identifier (CURIE) such as `OBI:0001271`
    */
    string id;

    /**
    The value of the owl:versionIRI field in the ontology
    */
    union {null, string} versionIRI;

}

Don't you have access to the MTT rolling minutes? Could you pls. send me/Stephen your email?
Michael.

On 16 Jun 2015, at 21:31, Paul Grosu<EMAIL_ADDRESS>wrote:
@helenp https://github.com/helenp If you could write up and post the meeting notes afterwards here, that would be very helpful. I'm still waiting for my approval to go through for the GA4GH DWG mailing list https://groups.google.com/forum/#!topic/ga4gh-dwg/Kf2Xaj31NWc.
Thanks,
Paul
—
Reply to this email directly or view it on GitHub https://github.com/ga4gh/schemas/issues/165#issuecomment-112539234.

Hi Michael,
My email is<EMAIL_ADDRESS>though I didn't think it would have been appropriate for me to join the call until I would be officially on the mailing list.
Regrading the MTT rolling minutes - I think I didn't scroll far enough - but would they be following?
https://docs.google.com/viewer?a=v&pid=forums&srcid=MTYzMjEzOTI0Mjc3MTc2Nzg1NjQBMDYyMTQ5MTgwNTE5OTg0OTk3NTkBbzkwWDVfS0NEeVVKATAuMS4xAQF2Mg
Thank you,
Paul

So far we have deferred a lot of the schema to use OntologyTerm or a list thereof. However, for many attributes and/or use cases, this won't be enough:

for data input/import with deferred mapping
for relevant and sometimes (by universal agreement, if not by special condition) simple/unanimous data (think geneticSex)
for evolving standards/multiple mappings (think disease classifications)

There will be many instances were e.g. the definition of a disease term won't be captured through a single OntologyTerm instance, or even through a list of those.
Now this can in principle be addressed in IMHO 3 ways:

through allowing references to local "ontologies" through a simple OntologyTerm object; however, they would have to be structurally well designed to be in line with external ontologies
through optional attributes, e.g. classType, classVersion, classTerm, classId ... as part of a OntologyTerm object, thereby allowing ad hoc storage of data without ontology curation
through having "fallback" descripting attributes like above as part of all/most parental objects using OntologyTerm, i.e. making the latter optional

In my opinion, the last variant is the most practical when considering a variety of scenarios (i.e. one can immediately make a local dataset GA4GH schema compatible for data mining purposes). Obviously, solutions making use of the schema should provide appropriate interfaces for making use of appropriate ontologies, and the schema documentation should encourage this.
Or provide proof of how these and more scenarios would be handled...

@pgrosu I think we can just add you for the next call June 18th  if that's of interest to you. MTT minutes here  https://docs.google.com/document/d/1QXKjGJCRlHu6AUPNL0-wjOVe-6_55p1DQ2CSGjlxelk/edit

Not much time to write, but one of the distinctions we discussed needing to make is regarding the semantics for when multiple terms are chosen. For example, if two disease terms are indicated, it would likely mean that the patient has two diagnoses (or two family members with them, or whatever the context). This is distinct from assigning two terms from different vocabs as alternatives, as @mbaudis indicates above. Then there are the semantics that might already be present between two terms indicated in this way. We also agreed that some uses of ontologyTerm would specify a single entity (e.g. you can only have one geneticSex), whereas others would expect an array (a set of phenotypes).
Everyone largely seemed to agree to use of CURIES and a CURIE map
Also, @mbaudis @diekhans and @nlwashington and I discussed compliance testing that would leverage OWL reasoning as part of the reference implementation to ensure best use.
Use of non-registered CURIES would go through a registration request to check appropriate usage (more than constraining people) or could be a local extension. I think we'd largely want to discourage local extensions, but some good documentation about how to best include and document them could go a long way.
The compliance suite would also check for consistent ID formats and unregistered CURIES, pointing people to the registration page or make alternative suggestions based on existing OWL file equivalencies/xrefs.

@helenp OK. I'd be interested to see the minutes from this meeting as I'm not part of the Metadata TT.

Hi Chris,
Since we area creating a data exchange API, we need to be able
to handle a lot of legacy data that might not conform to the
desired format.  This is the idea behind of local `ontologies'.
Even if we could, it would be a difficult to create validation
as part of the schema.
As you suggest, creating validation programs is a great solution.
It allows tuning for the data set and create more comprehensiveness
validation than can be created by declaration alone.
Cheers,
Mark
Chris Mungall<EMAIL_ADDRESS>writes:

@selewis are you attending the call on June 18?
My proposal is as follows:

The field id in the OntologyTerm object ( this one ) be constrained to
contain CURIEs (e.g. HP:0001234)
GA4GH endorses a set of CURIE prefixes that are consistent with the
standard URIs used for classes in that ontology, e.g. "HP": "http://
purl.obolibrary.org/obo/HP_"

Note that (1) cannot be enforced within Avro AFAICT, but it would be trivial to
write some kind of checker as an additional layer.
Note that this proposal can be seen as a subset of proposal #311 to use JSON-LD
ubiquitously - however, the proposal in this ticket is in no way dependent on
GA4GH endorsing JSON-LD in whole or in part.
For (2), the CURIE map could live within the GA4GH github repository (and sync
with external sources), or it could point outwards to an externally maintained
set of CURIE prefixes (e.g. this obo context. Note there is no requirement for
programmatic consumers or producers of GA4GH json, avro, services to be able to
process a prefix map or json-ld file. The prefix map will be primarily a social
contract to ensure that the same class is referred to in the same way.
This proposal is neutral w.r.t whether a single ID or multiple IDs are used in
an annotation (e.g. the disease scenario, where someone may want to record a
NCIt class and a SNOMED class and a DOID class).
Note that some schemas (e.g. MME ) may opt not use the OntologyTerm container
and instead use a direct reference to an id field. In this case, I would
recommend the same guidelines are followed.
This proposal does not explicitly address versioning, but is compatible with a
number of different schemes. As a strawman:
record OntologyTerm {
/**
A prefixed identifier (CURIE) such as OBI:0001271
*/
string id;
/**
The value of the owl:versionIRI field in the ontology
*/
union {null, string} versionIRI;

}
—
Reply to this email directly or view it on GitHub.*

Hi Helen,
Thank you for the minutes, which are very helpful in getting me caught up
with the project.  I am still carefully going through them, and previously
I was referring regarding waiting to join the DWG list in order to join
those calls - though the MTT ones could be quite pertinent for me as well.
Having worked with interfacing with ontologies before, I would like to get
up to speed on the materials before joining the MTT calls, since there is
quite a lot to catch up to.
I was unaware of the MTT minutes, which I think many would find very
helpful to properly contribute to.  It might be very helpful if the link to
the minutes from all the teams are posted on the GA4GH website and on
GitHub (https://github.com/ga4gh/).  This would probably be the quickest
way for people to synchronize on all the projects.
Thank you,
Paul
On Tue, Jun 16, 2015 at 5:20 PM, Helen Parkinson<EMAIL_ADDRESS>wrote:

@pgrosu https://github.com/pgrosu I think we can just add you for the
next call June 18th if that's of interest to you. MTT minutes here
https://docs.google.com/document/d/1QXKjGJCRlHu6AUPNL0-wjOVe-6_55p1DQ2CSGjlxelk/edit
—
Reply to this email directly or view it on GitHub
https://github.com/ga4gh/schemas/issues/165#issuecomment-112572871.

@pgrosu  - there's a lot of process documentation in the minutes. The MTT is now ticketing all relevant items and better documenting these so that they are standalone. My preference is to use tickets as they are cleaner.

@helenp Ah, makes sense.  Would these tickets be through MetadataTaskTeam labels as follows, or via another method (i.e. a different stored location):
https://github.com/ga4gh/schemas/labels/MetadataTaskTeam
Knowing the method would able people to quickly get a glance on the status, and not fall behind on the progress.
Thanks,
Paul

@pgrosu Labels. We have done some clean up

@helenp Super, thank you :)

On Tue, Jun 16, 2015 at 12:35 PM, Chris Mungall<EMAIL_ADDRESS>wrote:

@selewis https://github.com/selewis are you attending the call on June
18?

Yes, I'll be on the call. But I have a lot of homework to do to catch up
with everything that happened while I've been away.

My proposal is as follows:

The field id in the OntologyTerm object ( this one
https://github.com/ga4gh/schemas/blob/master/src/main/resources/avro/ontologies.avdl#L21
) be constrained to contain CURIEs (e.g. HP:0001234)
GA4GH endorses a set of CURIE prefixes that are consistent with the
standard URIs used for classes in that ontology, e.g. "HP": "
http://purl.obolibrary.org/obo/HP_"

Note that (1) cannot be enforced within Avro AFAICT, but it would be
trivial to write some kind of checker as an additional layer.
Note that this proposal can be seen as a subset of proposal #311
https://github.com/ga4gh/schemas/issues/311 to use JSON-LD ubiquitously

however, the proposal in this ticket is in no way dependent on GA4GH
endorsing JSON-LD in whole or in part.

For (2), the CURIE map could live within the GA4GH github repository (and
sync with external sources), or it could point outwards to an externally
maintained set of CURIE prefixes (e.g. this obo context
https://raw.githubusercontent.com/cmungall/biocontext/master/registry/obo_context.jsonld.
Note there is no requirement for programmatic consumers or producers of
GA4GH json, avro, services to be able to process a prefix map or json-ld
file. The prefix map will be primarily a social contract to ensure that the
same class is referred to in the same way.
This proposal is neutral w.r.t whether a single ID or multiple IDs are
used in an annotation (e.g. the disease scenario, where someone may want to
record a NCIt class and a SNOMED class and a DOID class).
Note that some schemas (e.g. MME
https://github.com/MatchmakerExchange/mme-apis/blob/master/search-api.md#example
) may opt not use the OntologyTerm container and instead use a direct
reference to an id field. In this case, I would recommend the same
guidelines are followed.
This proposal does not explicitly address versioning, but is compatible
with a number of different schemes. As a strawman:
record OntologyTerm {
/**
A prefixed identifier (CURIE) such as OBI:0001271
*/
string id;
/**
The value of the owl:versionIRI field in the ontology
*/
union {null, string} versionIRI;

}
—
Reply to this email directly or view it on GitHub
https://github.com/ga4gh/schemas/issues/165#issuecomment-112540419.

--
In the long history of humankind (& animal-kind too) those who learned to
collaborate & improvise most effectively have prevailed - Charles Darwin

@mbaudis you mentioned a few days ago "Still, there hasn't been implementation work on the exact format of the  ontologyTerm  object; everybody is welcome, regarding the notes above ...".  in creating the FuGE standard a few years back, we thought long and hard about this.  the UML model we came up with was this:

we were interested in allowing both simple cases (i.e. no properties involved) and the ability to describe more complex terms, such as an automobile that would have properties for such things as engine, tires, etc.  a brief usage document is here.  the UML was implemented as XML for the standard but should map to RDF easily.

Aside: not sure what the GA4GH protocol is here but it feels like we should be spinning new issues here?
@mdmiller53 - thanks for sharing the doc. I'm not sure it precisely aligns to GA4GH requirements (though we may all have different ideas about what these are). The typical usage would be to represent an ontology class (rather than property or individual, if by individual you mean something like owl individual). There are situations where we may want to denote a property (aka relation) too (for example, in a generic functional annotation model). There may be situations where we want to model composition of ontology terms (see this UML ) but this is probably best discussed as a separate issue from the format of the class references.

Hi I have been traveling like crazy (could not even attend the meetign in my home town) and apologize for not being in many calls lately, but I suppose that once Beacons go 'ontology' we adhere to FAIR and ELIXIR interop. developments?
Regards
Barend Mons
sent from a mobile device
<EMAIL_ADDRESS><EMAIL_ADDRESS>
On Jun 19, 2015, at 01:26, Chris Mungall<EMAIL_ADDRESS>wrote:
Aside: not sure what the GA4GH protocol is here but it feels like we should be spinning new issues here?
@mdmiller53 - thanks for sharing the doc. I'm not sure it precisely aligns to GA4GH requirements (though we may all have different ideas about what these are). The typical usage would be to represent an ontology class (rather than property or individual, if by individual you mean something like owl individual). There are situations where we may want to denote a property (aka relation) too (for example, in a generic functional annotation model). There may be situations where we want to model composition of ontology terms (see this UML ) but this is probably best discussed as a separate issue from the format of the class references.
—
Reply to this email directly or view it on GitHub.

Hi All
New to the group, so please excuse if this has already been worked out...
...for any specified phenotype ontology term, how will one distinguish
between the different things you might want to communicate with/about
that term, e.g.

ontology item 'was observed' = yes/no (definitive)

ontology item 'has value' = XYZ (qualitative)

ontology item 'was assessed' = yes/no (tested)

etc
The FuGE model seems like it might have that covered (via
OntologyProperty??), or perhaps that is just about defining the term
itself?
Has this group yet got deeply into the differential use of ontologies in
schemas, exchange and queries, as oppose to the means for specifying the
term itself?
Cheers
Tony
Professor Anthony J Brookes
Department of Genetics
University of Leicester
University Road
Leicester, LE1 7RH, UK
Tel: +44 (0)116 2523401

mdmiller53 wrote:

@mbaudis https://github.com/mbaudis you mentioned a few days ago
"Still, there hasn't been implementation work on the exact format of
the ontologyTerm object; everybody is welcome, regarding the notes
above ...". in creating the FuGE
http://fuge.sourceforge.net/dev/index.php#v1Final standard a few
years back, we thought long and hard about this. the UML model we came
up with was this:
ontology
https://cloud.githubusercontent.com/assets/1576739/8241367/c97cb676-15bd-11e5-98ab-72a7d40b864e.png
we were interested in allowing both simple cases (i.e. no properties
involved) and the ability to describe more complex terms, such as an
automobile that would have properties for such things as engine,
tires, etc. a brief usage document is here
http://fuge.sourceforge.net/presentation/fuge_ontology_best_practice.doc.
the UML was implemented as XML for the standard but should map to RDF
easily.
—
Reply to this email directly or view it on GitHub
https://github.com/ga4gh/schemas/issues/165#issuecomment-113282379.

@antbro Can we keep to the issue of the topic please? =] Do by all means create a new issue!

Was it really so off topic? (any more than other posts in the thread,
e.g., questions of how to refer to multiple ontology terms per individual)
To be clear, I was not seeking a discussion, just an answer to a
question centrally related to ontology IDs...
...so can I take it from your response ("create a new issue") that the
answer to my question is "we have not talked about that aspect yet"?
Cheers
Tony

@antbro https://github.com/antbro Can we keep to the issue of the
topic please? =] Do by all means create a new issue!
—
Reply to this email directly or view it on GitHub
https://github.com/ga4gh/schemas/issues/165#issuecomment-113450486.

@antbro What you refer is not part of the ontologyTerm object itself, but could be defined through some kind of "evidence" objects. This is under development in G2P, I think, but should be moved "mainline".
Can we maybe start this over, through a PR against https://github.com/ga4gh/schemas/blob/master/src/main/resources/avro/ontologies.avdl ? I have moved the metadata implementations to this branch.

Agree with @mbaudis and @Relequestual
This ticket has meandered (and I am partially to blame for this above, reporting on Leiden discussion). Can everyone please make new tickets for these individual items and keep this one only to how avro references IDs for OntologyTerm?
@antbro please review G2P schema that was recently accepted and see if this addresses your questions sufficiently
https://github.com/ga4gh/schemas/blob/master/src/main/resources/avro/genotypephenotype.avdl#L77
Please make tickets there for gaps/issues, much appreciated.

After having worked with the existing Ontology model for a while, we've proposed some small changes that should close this issue. https://github.com/ga4gh/schemas/pull/694

Closed with https://github.com/ga4gh/schemas/pull/694
Current discussion regarding the use of ontology terms continues here.


Huggingface Api key through config results in error call

When using api key in configurations for an huggingface provider (Tinyllama), the call results in the following error:
API call error: The following model_kwargs are not used by the model: ['apiKey'] (note: typos in the generate arguments will also show up in this list)
I suppose that the api key should be removed from configurations when the package makes the api call and should be used only in headers.

Thank you for your wor

Fix released in 0.44.0


Migrate build_system, exceptions, and source to null safety

build_system, exceptions, and source all imported each other, and needed to migrate together.
Move globals.buildSystem to globals_null_migrated, update imports where possible.
Part of #71511

Google testing failing because https://github.com/flutter/flutter/pull/83073 hasn't rolled yet.


ci: change to use github action runners

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 77.80%. Comparing base (3f935d5) to head (9ce2359).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2915      +/-   ##
==========================================
- Coverage   77.83%   77.80%   -0.03%
==========================================
  Files         231      231
  Lines       70199    70199
  Branches    70199    70199
==========================================
- Hits        54641    54620      -21
+ Misses      12691    12685       -6
- Partials     2867     2894      +27

Flag
Coverage Δ

unittests
77.80% <ø> (-0.03%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

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


Support Pre-Built Non-JS Scripts (Wrap Scripts)

Currently the scripts created by the script-writer have the following limitations:

Must be vanilla JS
Can only use whitelisted packages (axios, fs, etc)

In order to overcome these limitations, we can utilize pre-built wraps, as they can:

be built in multiple languages (rust, go, typescript/javascript, assemblyscript)
utilize external packages

The evo agent functions could be structured in the following way to support this:
evo.findScript
  - query-local-scripts
  - query-ext-scripts

evo.importScript
  - write-wrap-script

evo.createScript
  - write-js-script

Wrap scripts could look something like:
{
  "name": "namespace.function",
  "description": "...",
  "arguments": "{ arg: string }",
  "code"<EMAIL_ADDRESS>}

Just talked to @cbrzn about the implementation of this. Here is a draft webScrape.getLinks.json file:
{
  "name": "webScrape.getLinks",
  "description": "Get all links from a web page",
  "arguments": "{ ... }",
  "code": "wrap://wrapscan.io/polywrap/web-scrape"
}

The implementation of this could be done in 2 parts. First is supporting pre-defined "wrap scripts" like shown above, that evo simply knows how to execute. The second step would be adding support for searching through wraps and generating the above JSON file from a wrap ABI.
The list of "known wraps" can be hard-coded for now, and in the future could be pulled from an external service like wrapscan.

Just talked with @rihp and he noted that most web-scraping tests are failing in the benchmarks, so adding support for pre-built scripts (aka wraps) is very important for continuing our progress. First one to be added should be the web-scraper.

I created this test branch to make sure the wrap scripts work as expected: kris/invoke-wrap-test
Invocations fail on my local machine. I'm not sure why.
const result = __wrap_subinvoke(
  "wrap://ipfs/QmXKA6qc3TMiBZn5DyydYwdc9o2uSShqFdV7yTgYjF2xdu",
  "get_links",
  { uri }
)
if (!result.ok) {
  throw result.error;
}
return result.value;

Nevermind, I confirmed it works. The issue is in the web scraper wrap.

You can confirm that wrap scripts work using the fibonacci test script in the branch kris/invoke-wrap-test


expect(0) error doesn't have useful stack trace

When a test has no assertions, QUnit throws "Expected at least one assertion, but none were run - call expect(0) to accept zero assertions".
Because this error is inside QUnit code and not test code, the exception information is not very useful. At first glance, it seems like it may be impossible to provide better information, but I'm opening this ticket to try to brainstorm a better solution.

I see no way to add a useful stack trace in this case. In af27eae841c3e1c01c46de72d676f1047e1ee375 I actually remove the useless trace for unmatched expect and expect(0), so that's at least better then pointing to some line inside qunit.js.