Sighting: Stratux drop out

Stratux version:1.3b3

Stratux config:
SDR

[ ] single
[ X] dual

GPS

[X ] yes
[ ] no
type:  GPYes

AHRS

[ X] yes
[ ] no

power source: Airplane (USB Port)
usb cable: um, yes?

EFB app and version: (e.g., WingX Pro7 8.6.2)  FF, beta
EFB platform: (e.g., iOS 9.2) 10.3.x (latest, whatever version that is)
EFB hardware: (e.g., iPad Mini 2) iPad Mini 2

Description of your issue:  A sighting: while on a set of long flights (2-3 hours each) over this last weekend, I saw FF showing ADS-B towers (i.e. connected to Stratux), but NO ADS-B data. Speed went to zero, position went to zero, the FF airplane went to a blue pulsing dot, "remaining" data was missing in the navlog. In one instance, the data came back by itself within a minute or so. In another case, I rebooted the Stratux (power cycle) after 2-3 minutes. When it re-occured, I simply powered off the stratux and utilized the iPad GPS for FF data (at this point, I was 2.5 hours out from my destination. In total over three days, I flew 18+ hours).  Earlier, I had checked Stratux temperature and seen that it was around 51 degrees C. Note: in my plane (Aircoupe) the GPS has sky view through the canopy.

If possible, enable "Replay Logs", reproduce the problem, and provide a copy of the logs in http://<IP_ADDRESS>/logs/stratux/ and http://<IP_ADDRESS>/logs/stratux.log.

This just happened to me today, although mine might not be a representative sample. (I've sh'd up to an Eric build, and then back down to a Chris build. ) Also, my Stratux has been on for about 4 hours in the house (AC set for 83) and is quite warm in a Chris box, with no fan and copper foil shield around to make it a little oven. Am also getting "stuttering" of the web UI, as if packets aren't making it thru or are being delayed or sent real slow. https://vid.me/bGy2d

I also had mine drop out completely, no traffic no GPS but the box was still running and wifi on  v1.3b2
c6e96b5.  I was flying my checkride so I didnt trouble shoot it but it really threw me off my game (Instrument check), still passed though.  I have since updated to the new b3 but have not flown since.

daveholland86, you got to use stratux during the instrument checkride? Ipad?

Yes I was using Foreflight with electronic terminal procedures.

Any limitation what you cannot use the ipad/ foreflight for? Doing my IFR training, and i like my ipad. My panel mount certified gps is not a moving map.

No.  Its only to be used to for situational awareness, so the gps approaches will be loaded in the the panel mount gps and nav from the VOR dial.  You can verify your position on the ipad but its not official.  I used it for flying my enroute, and approach and departure plates and keeping track where I was on the approach.  Its good to see the aircraft on the leg segment and get the stepdown altitudes.

I've confirmed this issue last weekend. On a 1.25hr flight, ForeFlight showed "ADS-B Disconnected" 3-4 times. Uptime on Stratux (gdl90_daemon) showed 55min+ at the end and no crashes/errors. It happened on my iPad Mini 2, but my passenger had ForeFlight on his iPad Mini 4 and experienced zero disconnects.
Tagging this as a ForeFlight issue. It popped up in ForeFlight 9.2.

@daveholland86 - which iPad were you using?

@cyoung , I wonder if this is hardware/iPad performance related.  I also have a Mini 2 and see the same behavior.  Do you have Hide Distant Traffic enabled?  I am wondering if we hit a certain volume of ADS-B messages that just overwhelms the Mini 2.
My next flight I am going to try and hide Distant Traffic to see if I see the same disconnect messages.  Theory is that hiding distant traffic might free up some resources on the iPad.

Do not have "Hide Distant Traffic" enabled.
Thanks for your report, so far all the confirm disconnects are on Mini 2's.

	I hide distant traffic on my Ipad mini, and still had disconnects, HOWEVER, on recent flights in light traffic environments haven't had a single disconnect.

	Get Outlook for iOS

On Tue, Aug 22, 2017 at 11:38 AM -0400, "pmaag"<EMAIL_ADDRESS>wrote:
@cyoung , I wonder if this is hardware/iPad performance related.  I also have a Mini 2 and see the same behavior.  Do you have Hide Distant Traffic enabled?  I am wondering if we hit a certain volume of ADS-B messages that just overwhelms the Mini 2.
My next flight I am going to try and hide Distant Traffic to see if I see the same disconnect messages.  Theory is that hiding distant traffic might free up some resources on the iPad.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

I am flying in a plane tomorrow that has a Stratus 2s.  If the Mini 2 performance theory is accurate, I should see these disconnect messages tomorrow during that flight.  Obviously the Stratus could be doing some device-side throttling, but will be an interesting test.
I'll report back after the flight tomorrow.

@jpuetthoff - thanks for the report. Which Mini do you have? On the back of the iPad it should say "Model A____".

	I will check as soon as I can. Thought it was a mini 2. Will verify. Case fits a mini 1 and 2.

	Get Outlook for iOS

On Tue, Aug 22, 2017 at 11:44 AM -0400, "cyoung"<EMAIL_ADDRESS>wrote:
@jpuetthoff - thanks for the report. Which Mini do you have? On the back of the iPad it should say "Model A____".
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

I am not sure this is a Foreflight issue.  See the attached packet capture taken on the Stratux during an "ADS-B Disconnected" event.  Here is my summary:
Foreflight reported the disconnect at 08-21-2017 22:01:14Z
Packet #10 in the capture is the last UDP packet sent from Stratux to the Foreflight client.
Packet #13 is the Stratux attempting to ping the iPad.  Never receives a reply.
Packet #72 is the Stratux attempting to ping the iPad.  Never receives a reply.
Packet #91, the iPad sends a broadcast UDP packet with DST port of 50113, content: "i want to play - ffm - udp"  Appears to be some sort of heartbeat.
Packet #156 is the Stratux attempting to ping the iPad.  Never receives a reply.
Packet #219 is the Stratux attempting to ping the iPad.  Never receives a reply.
Packet #239 another iPad heartbeat (same as packet #91) to broadcast, so we know the iPad is on the network.
Packet #291 another Stratux ping to the iPad, no response received.
Packet #355 another Stratux ping to the iPad, no response received.
Packet #375 another iPad heartbeat to broadcast, iPad definitely on the network.
Packet #426 Stratux ICMP to iPad, this ICMP is replied to by the iPad.
Packet #435 Stratux starts sending UDP once again to the iPad.
So from the looks of it, the iPad will stop replying to ICMP messages during times of high CPU usage/performance issues?  This causes the Stratux "heartbeat" to the iPad to drop, which stops the flow of UDP.  Once the iPad starts replying to ICMP once again, things begin to flow correctly.
Suggestion: Use ARP instead of ICMP to test device reachability.  Usually ICMP is the first protocol to be dropped once CPU usage gets high.  ARP is normally not deprioritized and can simply be checked by issuing an ARP request and looking for the entry within the Stratux's ARP table.
Thoughts?
ads-b_disconnected_filtered.zip

Sorry, I just got notification today.  I have a Mini 2 64gb.

@cyoung - I have been working on the code for this fix and have something working.  Looking for some direction on how you want to proceed, as there are some trade-offs (at least for iOS clients):
Here is how my code currently is working (in the following order):

If client has issued an ICMP Unreachable to UDP 4000 within the past 5 seconds, immediately report as sleeping.

else

If client has sent a FF heartbeat broadcast in the past 10 seconds, report as awake.

else

If client has not responded to ICMP request and has no MAC address in ARP table, report as sleeping.

else

If client has responded to ICMP request within the past 30 seconds, and has a MAC address in ARP table, report as awake.

#2 & #4 are essentially the "second chance" for the older hardware that might be resource constrained at the ICMP layer but still active within the EFB.
The downside to #4 is that when a client is physically put to sleep (press of the power button), iOS has strange/inconsistent behavior.  In my testing the iPad sometimes responds to ICMP (very intermittent and high latency), but always responds to ARP.  This results in the client flapping between awake and sleep, since #4 marks the client as awake but then the client immediately issues ICMP unreachables when the stratux starts up the GDL90 stream (FF is not running).  The flap is just a second, so the client will stay in sleep for 4 out of 5 seconds, but the flapping does occur.
Part of me thinks we should just have #2 and remove the check in #4, however other EFBs might not send a FF heartbeat (they likely don't), so we could see issues with those clients disconnecting when/if they start dropping ICMP due to hardware performance.
Any suggestions are appreciated.  I am taking my code flying tonight and tomorrow and I definitely think it will fix the "ADS-B Disconnected" issue, however I don't sleep my iPad during flights so I am not sure how the flapping would affect me.

Just an FYI, flew for 4.4 the past two days with my updated code described above and received zero "ADS-B Disconnected" errors. Normally I would have seen at least 3-8 instances during that length of time.

Just want to add my name to the list. Flew this Saturday on (2) 2 hour legs and for the first time started seeing the "ADS-B Disconnected" message in FF. Distant traffic hidden. UI behavior as others indicated. At the time running 1.4r1 (just upgraded to r2) on a Mini 2 (32GB).

Throwing my name in. 1.4r2 / iPad Mini / FPG.
Flight 1.0 hour. Stratus shows running 1.5
Counted 8 disconnects in flight.

Still an issue yesterday. Since I was flying it was hard to troubleshoot the source of the problem.

@mrdoornbos - which app? iPad Mini/Mini2?

I flew for about 90 minutes yesterday.  I saw between 8 and 10 disconnects.  iPad Pro 10.5 with iOS 11.0.2.  I didn't see any disconnects for about 20 minutes into the flight, which made me wonder if it was heat related, even though I have the PWM controlled fan.

	I have asked myself the same thing if it is heat related on the iPad side. My ipad is in a case on a cradle.

	Get Outlook for iOS

On Sat, Oct 7, 2017 at 10:01 AM -0400, "JohnOCFII"<EMAIL_ADDRESS>wrote:
I flew for about 90 minutes yesterday.  I saw between 8 and 10 disconnects.  iPad Pro 10.5 with iOS 11.0.2.  I didn't see any disconnects for about 20 minutes into the flight, which made me wonder if it was heat related, even though I have the PWM controlled fan.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Noticed this post on FF Facebook page under the topic "We're testing iOS 11.0.2 with ForeFlight" and it made me wonder if this actually a FF issue ...
https://www.facebook.com/pg/foreflight/posts/
 I've experienced connectivity issues between Stratus 2S and Foreflight. I'm running the latest iOS. 2 hour night flight ... iPad showed the wifi connection was still active and online. Foreflight's device page showed Stratus connected and sharing data but the map said zero towers at 3500ft. GPS accuracy 5m. (iPad) No traffic on the map.  Had to do this three times in mid air. This happened at least once with the previous version of iOS. Only three flights so far with stratus.

@cyoung iPad Mini 4, Foreflight 9.4.1, iOS 11.0.2, Stratux 1.4r2
I'll grab it out of the plane on my way home and look at the logs.

I'll try it with a Trial version of Garmin Pilot just for fun on the same iPad to see if I see anything different.

Sounds like ForeFlight hasn't finished their compatibility testing with iOS 11.0.2 in the week that it has been out. My guess is that they're preparing a fix for these issues. We don't have any other users (FlyQ, WingX, etc) reporting this issue yet.

This appears to have gotten quite a bit worse.
Reproduced it even with sleep mode completely disabled, so there's something more going on.
(change isSleeping() to return false always): https://github.com/cyoung/stratux/blob/master/main/network.go#L147-L162
@pmaag - have you found anything else? Seems like it's much easier to reproduce now with iOS 11 and latest FF (9.4.1).
Use this to help reproduce:  ./gen_gdl90 -replay -uatlog test-data/cyoung-09062015-noproblem-stratux-uat.log -speed 10
Tag #660.

I have been swamped recently, I never heard back from anyone on my proposed
changes. From my testing it really did help the issue.
Can you run your tests on the PR code i submitted to validate?
On Thu, Oct 12, 2017 at 4:47 PM cyoung<EMAIL_ADDRESS>wrote:

This appears to have gotten quite a bit worse.
Reproduced it even with sleep mode completely disabled, so there's
something more going on.
(change isSleeping() to return false always):
https://github.com/cyoung/stratux/blob/master/main/network.go#L147-L162
@pmaag https://github.com/pmaag - have you found anything else? Seems
like it's much easier to reproduce now with iOS 11 and latest FF (9.4.1).
Use this to help reproduce: ./gen_gdl90 -replay -uatlog
test-data/cyoung-09062015-noproblem-stratux-uat.log -speed 10
Tag #660 https://github.com/cyoung/stratux/pull/660.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cyoung/stratux/issues/631#issuecomment-336311527, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB-EcKGbS_oAerXCJ5DJsRG-hwMaFQHiks5srqUEgaJpZM4OOTmo
.

It might have been coincidental because if the disconnect happens with no sleep mode, then changing the sleep mode criteria shouldn't help much.

https://youtu.be/VkypNVu03l8
iPhone 6s, iOS 11.0.2, ForeFlight 9.4.1.
Stratux UAT log replay @ 10x.
Stratux "sleep mode" disabled. See /getClients at the end (no clients are in sleep mode). Unit is sending GDL90, Wi-Fi is working, but ForeFlight detects no devices.

Very interesting. I am running Foreflight 9.4.1 on iOS 10.x on a Mini 2.  I
will try and get some time to run some tests as well.
On Oct 12, 2017 5:09 PM, "cyoung"<EMAIL_ADDRESS>wrote:
https://youtu.be/VkypNVu03l8
iPhone 6s, iOS 11.0.2, ForeFlight 9.4.1.
Stratux UAT log replay @ 10x.
Stratux "sleep mode" disabled. See /getClients at the end (no clients are
in sleep mode). Unit is sending GDL90, Wi-Fi is working, but ForeFlight
detects no devices.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cyoung/stratux/issues/631#issuecomment-336314800, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB-EcLk1yAxt_d3eo1xFxJe9vxztj8f_ks5srqo3gaJpZM4OOTmo
.

Foreflight 9.4.1 IOS 10.3.3.
I reset my iPad to see if it was a conflict, and it improved but still having issues.
I re-downloaded the software for Stratux. To make it work, I have to close the FF, and re-open it, and it will find the ADS-B. It will only work for a few minutes before it gets disconnected.

Any solutions yet? I am using an iPad mini 4 with the newest iOS and Foreflight. I am flying every day approx 6h. I have disconnect about every minute. Makes no sense for me to use it anymore.

I am having the same issue. Disconnect ADS B notice every couple of minutes. I have to close FF app each time and relaunch to get it back momentarily before it disconnects again. It’s so bad now that it’s become a distraction in the cockpit. It’s worthless in its current state. Any fixes yet?

This is a ForeFlight bug. I've been trying to figure out what triggers it, but it's not obvious.
Stratux is working great (as usual) in every other app.
Best bet right now is to send a note to<EMAIL_ADDRESS>and let them know that they broke it.

Yes, I tested it with FlyQ EFB and Wing X. No problems. Works great.

I've let them know since the beginning of the ticket but it has gotten worse with the recent releases.
Best bet is to send them a note so that they know that it's affecting more than just a few select users.

I just sent them an email and received already a reply.
Hi Dan,
William here - thanks for the email.
ForeFlight's stance on Stratux is neutral at the moment. If you want to use it, that’s great. You can view in-flight weather and traffic data from Stratux in ForeFlight Mobile, and we have no plans to block it from connecting to ForeFlight Mobile. That said we don’t have a formal agreement or partnership with the Stratux developers so you’ll need to look to the Stratux community for support resolving any Stratux-related issues.
The Stratux experimental AHRS data (https://github.com/cyoung/stratux/wiki/FAQ#is-ahrs-working-can-i-use-stratux-to-power-my-efbs-synthetic-vision) isn't currently displayed by ForeFlight Mobile and I do not have any timeline for if or when that might change.
If you haven't yet built a Stratux and are looking for a low-priced ADS-B receiver option, I encourage you to check out the Scout: it's a super-compact dual-band ADS-B receiver that runs all day on a single-cell battery and works great with ForeFlight Mobile, and only costs $199. Find out more at flywithscout.com.
Regards,
William
Pilot Support Team
<EMAIL_ADDRESS>

Nice canned response support and upsell. I think they don't even read incoming support emails unless you're following up for the second or third time. At least that has been my experience.

Any idea why Steve @ Seattle Avionics indicates "Do not use version 1.4r2 as it’s experimental and does not work w/ FlyQ EFB.  1.4r3 has been released but we are still testing it" on their ADS-B / GPS Device Status page? https://seattleavionics.wordpress.com/2017/10/12/ads-b-gps-device-status/
@cyoung May be worth reaching out to Steve for clarification ... I hope the timing of when we all noticed these ADS-B disconnects in FF is not related to when Scout was released (despite the comment from Support in Dan's reply).

That was confusion on release naming, Steve was referring to the dangerzone v1.4r2 build which sends two types of packets and was confusing FlyQ. All of the issues here concern the main branch.

Hello,
I experienced the same adsb disconnections.
I use foreflight / stratux about 5hrs a day, whem it disconnects I loose my GPS position, traffic but weather is still displayed. sometimes it comes back by itself, sometimes I need to restart FF.
It is pretty bad and distracting.
Sent an email to FF support.

Here’s the reply email I received..
Hi Zane,
Steven here. Thanks for the email and for the thoughts. ForeFlight's stance on Stratux is neutral at the moment. If you want to use it, that’s great. You can view in-flight weather and traffic data from Stratux in ForeFlight Mobile, and we have no plans to block it from connecting to ForeFlight Mobile. That said, we do not have a formal agreement or partnership with the Stratux developers so you’ll need to look to the Stratux community for support resolving any Stratux-related issues.
The Stratux experimental AHRS data isn't currently displayed by ForeFlight Mobile and I do not have any timeline for if or when that might change.
As you have learned, the Scout is fully integrated with ForeFlight. And another option if you want the AHRS and other units is the Stratus 2S.
Let us know if there is anything else that we can help you with.
Blue Skies,
Steven
Pilot Support Team
<EMAIL_ADDRESS>I’m sure if there was $$ involved things would start working very quickly.. I’m thinking about just changeing EFB’s. This basically just says buy one of our products if you want it to work.

I've just reproduced the issue with the Scout.
I didn't catch the exact moment when it disconnected (just left the iPad on for 10-15 minutes and it happened). But in the screen capture below, you'll see how the iPad is connected to Scout and I need to swipe to close ForeFlight and re-open it for the ADS-B connection to reestablish.
https://youtu.be/Spaf2ed7nwI
iPad Mini 2, iOS 11.0.2, ForeFlight 9.4.1.
Scout Wifi version: 1.3.1.
Scout Firmware: 2.3.6.

+1 same issue.  Everything was perfect before the update to FF 9.4.1.  Stratux v1.4r1, iPad Mini 4 WiFi, iOS 10.3.3.
During a flight tonight FF was losing its connection every 10-15 seconds.  Force close / restart and it came back with a connection, which would drop almost immediately.  I've reported to ForeFlight support and linked to this thread.  Expect a canned response in 3..2..1...

Response from ForeFlight support:

The logging function & messages were developed for supported devices so the in the logs info re: Stratux may not be reliable, but we are going to take a good faith look at this to see what's going on.

I received a follow up email yesterday..
Hi Zane,
Following-up with Steven's email, though Stratux is not one of our officially supported devices, on a "time available" basis we are looking into the reports of device disconnections from you and other pilots.
I don't have a timeline for when we'll have any updates, but it would be helpful if you could send us the following:

As best you can remember, when you started seeing the "Disconnected" messages.

Which version of iOS is on the device(s) where you've been seeing it. If you've seen it on multiple versions of iOS, please let us know that too.

Etc..
They asked if I could send another diagnostic log from Foreflight and Stratux so they could look more in depth into the situation. I happen to be flying this afternoon so I should have one to them by tonight.
Keep the emails rolling because I think we’re maybe getting somewhere.

My 2 cents. From my point of view "ADS-B has disconnected" issue doesn't appear limited to iOS version or hardware type.
Our rig:
Raspberry Pi  3 Model B
GPS V-162  (G-Mouse RoHS IPX6) DC 3.3V-5V

Stratux version:1.3b3

Stratux config:
SDR

single
[ X] dual w/ Dan Murray High Gain Antennas

GPS

[X ] yes
no
type: Vk-162

AHRS

[ X] yes
no

power source: Anker PowerDrive 5 usb cable: Anker

EFB app and version: FF 9.4.1
 (16238)
EFB platform: iOS 10.3.3 EFB hardware: iPad Mini 4    &
EFB platform: iOS 11.02 EFB hardware: iPad Air     &
EFB platform: iOS 10.3.3 EFB hardware: iPhone 6

Description of your issue: After four plus hours of flying over the past two days we had numerous (more than 20) dropouts. we tried rebooting everything and finally pulled out the Bad Elf GPS and enjoyed looking out the window. The dropouts happened individually on each device. The Stratux seemed to be working great. Lots of traffic, up to 8 towers seen and gps at 3m. Except when it dropped out.
Also, on the iPad Air received another error: "Download Error, Unable to connect to the network while connected to ADS-B."
This year we have flown the Stratux from the Maryland to Oshkosh and back, to New Maxico and up the East Coast with no hiccups until this recent trip. We are currently not happy with FF.

FWIW, FF is aware of the issue and trying to find it. It's way for us to bad-mouth them, but really it's just a part of the development cycle.
We need to be patient and continue to send them log files so they can track it down...
It could be worse - we could still be on paper charts. :-)
Josef
Sent from a phone with a tiny screen

On Oct 20, 2017, at 12:04 PM, MenFly2<EMAIL_ADDRESS>wrote:
My 2 cents. From my point of view "ADS-B has disconnected" issue doesn't appear limited to iOS version or hardware type.
Our rig:
Raspberry Pi 3 Model B
GPS V-162 (G-Mouse RoHS IPX6) DC 3.3V-5V
Stratux version:1.3b3
Stratux config:
> SDR
single
[ X] dual w/ Dan Murray High Gain Antennas
GPS
[X ] yes
no
type: Vk-162
AHRS
[ X] yes
no
power source: Anker PowerDrive 5 usb cable: Anker
EFB app and version: FF 9.4.1
>  (16238)
EFB platform: iOS 10.3.3 EFB hardware: iPad Mini 4 &
EFB platform: iOS 11.02 EFB hardware: iPad Air &
EFB platform: iOS 10.3.3 EFB hardware: iPhone 6
Description of your issue: After four plus hours of flying over the past two days we had numerous (more than 20) dropouts. we tried rebooting everything and finally pulled out the Bad Elf GPS and enjoyed looking out the window. The dropouts happened individually on each device. The Stratux seemed to be working great. Lots of traffic, up to 8 towers seen and gps at 3m. Except when it dropped out.
Also, on the iPad Air received another error: "Download Error, Unable to connect to the network while connected to ADS-B."
This year we have flown the Stratux from the Maryland to Oshkosh and back, to New Maxico and up the East Coast with no hiccups until this recent trip. We are currently not happy with FF.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

So I finally saw this issue yesterday. Ipad mini 3 iOS 11.0.3 Foreflight 9.42
My situation is a bit different than most since I fly in Canada and don't always see towers. I took off and had traffic as usual. As I headed south I started to pick up towers and starting seeing the disconnected message but it would come back after a bit of time without restarting Foreflight. It seemed to get worse as I got further south and any time I zoomed in on the map.
On the way back I turned off the UAT SDR to see if it would change anything and it did. No disconnections. Turned it back on and the disconnections started to occur immediately.
Did a bit of a side by side with my iphone 6 and it didn't seem to suffer the same thing. Only time I saw a disconnect on the iphone was when Foreflight first loaded.

As I headed south I started to pick up towers and starting seeing the disconnected message but it would come back after a bit of time without restarting Foreflight.

As a further data point, I ADS-B comes back without re-starting anything for me too.  I think others just aren't waiting.

Another data point. I can drive around all day in my car picking up some limited traffic but no towers, or just one intermittently when I’m close enough to the airport on the ground and have zero ADS-B disconnects. In the plane, in areas where I see towers consistently and a lot more dense traffic (not sure which is the problem) I got many dropouts. I’m running the PingEFB for what it’s worth.

@gpeterson,
Just an FYI: When I spoke with Foreflight Support a few months back on this
issue they let me know how/when that ADS-B message is sent:
"The ADS-B disconnect alert needs two things to happen. It needs you to be
airborne above 40 knots and it needs a loss of ADS-B data flow to the app
for a short period of time. "
So unfortunately that makes this much harder to troubleshoot as you
actually need to be airborne or somehow trick Foreflight into thinking it
is airborne.
Hopefully Foreflight finds this bug and can fix it.
On Oct 22, 2017 8:29 AM, "gpetersen"<EMAIL_ADDRESS>wrote:

Another data point. I can drive around all day in my car picking up some
limited traffic but no towers, or just one intermittently when I’m close
enough to the airport on the ground and have zero ADS-B disconnects. In the
plane, in areas where I see towers consistently and a lot more dense
traffic (not sure which is the problem) I got many dropouts. I’m running
the PingEFB for what it’s worth.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cyoung/stratux/issues/631#issuecomment-338486018, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB-EcCmQ9jk7QsBnaizeI_nuKFwBMNNNks5su19bgaJpZM4OOTmo
.

@pmaag Darn, that does complicate it.  Though even if the alert doesn’t pop, when driving I continue to get ADS-B GPS updates without interruption, which implies some condition that only happens when I’m flying may be at the root. Perhaps tied to the size or quantity of ADS-B updates that are being sent all at once.

Yeah I did do a bunch of work on the ground with packet captures, etc. (see
earlier post in this thread).  But it seems like something else is going on
internal to Foreflight.
On Oct 22, 2017 3:22 PM, "gpetersen"<EMAIL_ADDRESS>wrote:

@pmaag https://github.com/pmaag Darn, that does complicate it. Though
even if the alert doesn’t pop, when driving I continue to get ADS-B GPS
updates without interruption, which implies some condition that only
happens when I’m flying may be at the root. Perhaps tied to the size or
quantity of ADS-B updates that are being sent all at once.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cyoung/stratux/issues/631#issuecomment-338513922, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB-EcEQxrrBSChbxV5A47GcHrJHZoH1Nks5su8AkgaJpZM4OOTmo
.

@pmaag - sounds right on the "ADS-B disconnect alert", but that does not mean that we can't reproduce the issue on the ground. Just watch for the "Towers" indicator in the top left of the map to disappear. This is how I'm reproducing the issue on the ground. "ADS-B" also disappears from the Devices page when the disconnect happens.

FYI - Not sure if they have any more direct info from the folks at ForeFlight or not, but thought I'd share this update from OpenFlightSolutions.  https://www.openflightsolutions.com/service-bulletin-foreflight-disconnect-issue/?utm_source=All+FlightBox+Customers&utm_campaign=b26b214e28-EMAIL_CAMPAIGN_2017_10_23&utm_medium=email&utm_term=0_879b76cc88-b26b214e28-54761733&mc_cid=b26b214e28&mc_eid=7db96cb8e8

FYI - ForeFlight just released version 9.4.3 which the believe will fix the disconnect issue. They request that we enable the "Logging" option (More -> Devices -> ADS-B -> Logging) and send reports of any further issues to<EMAIL_ADDRESS>

Doing this again:

Use this to help reproduce: ./gen_gdl90 -replay -uatlog test-data/cyoung-09062015-noproblem-stratux-uat.log -speed 10

No disconnect on the iPad Mini 2 and iPhone 8, where it used to disconnect every time with FF 9.4.2.

Confirmed happening a couple of days ago on iPad Pro 10",  v1.4r2, FF, 9.4.2.

	FF update released today.

On Wed, Oct 25, 2017 at 12:35 PM -0400, "Seth Webster"<EMAIL_ADDRESS>wrote:
Confirmed happening a couple of days ago on iPad Pro 10",  v1.4r2, FF, 9.4.2.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

This happened to me over and over on a 3 hours flight yesterday. Upgraded to 9.4.3 this morning and will test again on my return flight tomorrow.

Summary: confirmed bug in ForeFlight 9.2+ was fixed in 9.4.3. Confirmed that it affected Stratux, Scout (officially supported by ForeFlight), and FreeFlight (officially supported by ForeFlight) from Jul 5th-Oct 25th. We didn't make any changes in Stratux during this time period that affected the issue.
I've reached out to try and establish some beta testing program so that Stratux users can participate to some extent in testing, or at least have someone's ear when there appear to be issues. Alas, such open communication with ForeFlight does not appear to be a possibility.

At some point they're bound to look in a mirror and notice the egg on their face.  I use an EFB that supports Stratux, and can't help but chuckle at the denial going on over at FF.  That Emperor ain't got no clothes on!

I flew about an hour and a half last night. The disconnection alerts were no longer popping up, but I never received traffic targets, and connection to towers was minimal at best. Fortunately, they're  working on the issue.

3 hours today on my return trip Washington DC and Asheville NC with no disconnects after going to 9.4.3.
Can confirm it appears to be resolved.

1.5 with multiple FF platforms. No drops. Yay!
Josef
Sent from a phone with a tiny screen

On Oct 27, 2017, at 8:25 PM, Michael Doornbos<EMAIL_ADDRESS>wrote:
3 hours today on my return trip Washington DC and Asheville NC with no disconnects after going to 9.4.3.
Can confirm it appears to be resolved.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Hi All, thanks @cyoung for the great open source Stratux!  I just bought a pre-made one on Amazon and ran into the "ADS-Disconnected" problem on my ForeFlight repeatedly this month.  My Stratux is with AHRS and was updated from v1.4r1 image to the latest dangerzone (http://updates.stratux.me/builds/dangerzone/update-stratux-v1.4r3-3b57564490.sh) update, on ForeFlight 9.4.3, and iOS 11.0.3, running on iPad 4 Mini 128GB version without WiFi.
I am not convinced this is 100% fixed yet as of today.  Just came back with 2 flights this weekend (10/28 and 10/29) from Yosemite.  Flight was following these VORs on v23: CZQ, EFH, GMN, 9,500 feet, then RNAV approach to SMO from DARTS intersection.  The entire 2 hour flight the "ADS-B Disconnected" message keeps on popping up, at least 20 time during my flight.  Any help would be greatly appreciated.  Like earlier commenters, it does seem to disconnect when there is heavier amount of traffic.  If I reboot the Stratux then it's good for about 10-15 minutes without disconnects, but then it would start disconnecting again after that.

When you connect to the Stratux and look at the Status page at <IP_ADDRESS>, how much disk space does it say is free?

Which "you"?
Josef
Sent from a phone with a tiny screen

On Oct 30, 2017, at 6:20 AM, Nokomis449<EMAIL_ADDRESS>wrote:
When you connect to the Stratux and look at the Status page at <IP_ADDRESS>, how much disk space does it say is free?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

"you" = @captainkw.  I had a similar issue to his several versions back where Stratux would drop out, lose towers, etc.  (I do NOT use ff).  I eventually tracked it down to my SD card being nearly full.  When I deleted the substantial log files that I had been accumulating, the issue went away.  I believe the current releases accumulate some log AHRS log files even with logging turned off in the user interface, and if the user doesn't expand the SD card the card can fill up - especially when we (I'm guilty of it) leave it running at home as a "gee whiz, look at this!" novelty.

Thanks @Nokomis449, it seems like I did not expand the SD card to full capacity, even though I did not have AHRS logs on.

Either way, I followed the raspberry pi instructions here to ssh and used the sudo raspi-config config utility to expand my SD card to full size (16GB):
https://github.com/cyoung/stratux/wiki/SSH-into-Stratux
https://coderwall.com/p/mhj8jw/raspbian-how-to-resize-the-root-partition-to-fill-sd-card
It looks like it's fully expanded now:

It won't be a week or two before I am able to fly with the Stratux unit, but if you don't hear from me again it can probably be assumed this issued is fixed.  Thanks all again for the help.

Ah. Got it. Thanks....
Josef
Sent from a device with a funny keyboard. Pardon the brevity and any typos....

On Oct 30, 2017, at 10:16 AM, Nokomis449<EMAIL_ADDRESS>wrote:
"you" = @captainkw. I had a similar issue to his several versions back where Stratux would drop out, lose towers, etc. (I do NOT use ff). I eventually tracked it down to my SD card being nearly full. When I deleted the substantial log files that I had been accumulating, the issue went away. I believe the current releases accumulate some log AHRS log files even with logging turned off in the user interface, and if the user doesn't expand the SD card the card can fill up - especially when we (I'm guilty of it) leave it running at home as a "gee whiz, look at this!" novelty.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Now that you can ssh in to the Pi, log in and execute sudo rm -f /var/log/stratux*
This will delete every file in the /var/log/ directory that starts with "stratux".  None of these files are necessary (it won't hurt anything to delete them) and they will be recreated the next time logging starts up.  Otherwise you'll just continue to append log info to the existing files and continue to slowly eat up disk space.

Looks like he had 170MB or so of free space, so I don't think that free space was causing the issue.
Another way to delete logs is to hit the version number a few times in rapid succession. Then a "Developer" tab will show up with "delete logfiles" functions.

Chris - is there any benefit / downside to resizing the partition?

Earlier versions of the AHRS added a lot of logging which caused free space to get used up quick. Recent .sh updates should remove the logs and don't have that issue so much.  That should be sufficient, IMO. Expanding the partition is good for development setups. We had an auto-expanding release earlier on and it caused a higher rate of SD card failures.

When I had my issue, I had a little over 100MB of room left; that's why I think it might be the problem. This guy here
[http://www.iflygps.com/Support/Forum/forumid/17/threadid/29528/scope/posts]
bought a pre-assembled Stratux and ran into an issue that was described as a similar problem.  Rather than fix it himself, he opted to get a new SD card.  Two weeks later with the new card, he had the issue again.  His screens say he has <50MB of space left, but the symptoms are similar.  That's why I think it's disk space related.  It'll be interesting to see if @captainkw 's issue is resolved by just expanding the partition.

I didn't know an .sh update cleared the logs - that might explain why we don't see more of this issue.

Ah, ok.
It does as of just a couple weeks ago. It's not in any of the release .sh updates but in the nightly builds.
http://updates.stratux.me/builds

It might be a good idea to somehow get the word out that if you see a steady blinking green light, you should check the Status page for an explanation.  I don't think very many owners even know about <IP_ADDRESS>, especially with all the pre-built units being shipped.

I finally got a chance to fly this weekend after returning from vacation.  Flew two flights, 1.0 & 1.4 hrs respectively.  I had one "disconnect" on each of the flights that required me to reboot FF.  So, it seems to be significantly improved but possibly still not 100%.  Whats everyone else seeing since the 9.4.3 update??

Seems to have settled quite a bit, haven't heard further reports since the update.

Not sure if this is the same problem but I flew about 8 hours using avare on my phone and true flight on a cheetah.  I noticed I lost signal to both units probably 5 times.  I reset the stratux by unplugging each time and it came back every time.

Interesting - flew 3.3 hrs on Sunday.
Two iPad Minis
My iPad had been updated to 11.1 and FF 9.4.3 - no disconnect messages
Co-Pilots iPad was still on 10.X  and FF 9.4.3 - constant disconnect messages
Would have thought FF fix was backward compatible but the issue we all reported must be tied to the OS

Looking back on this thread, looks like there is some people are still having issues with specific iPad iOS versions and FF versions.  I am happy to report that I flew 5.6 hours this weekend out of the busy SMO area to PAO and back, and had zero drops/disconnects from my Foreflight.  My configuration:

Pre-built Stratux from Everlasting Concepts: https://www.amazon.com/gp/product/B01LZTZ06C
iPad 4 Mini 128GB, running iOS 11.1, FF 9.4.3
Stratux Image: https://github.com/cyoung/stratux/releases/download/v1.4r3/stratux-v1.4r3-4de2420803.img.zip
Dangerzone .sh for AHRS: http://updates.stratux.me/builds/dangerzone/update-stratux-v1.4r3-3b57564490.sh
I also followed the following instructions to use the sudo raspi-config config utility to expand my SD card to full size (16GB):
https://github.com/cyoung/stratux/wiki/SSH-into-Stratux
https://coderwall.com/p/mhj8jw/raspbian-how-to-resize-the-root-partition-to-fill-sd-card

I saw there is a new dangerzone .sh on 11/18/2017 but I didn't use it as it came out after my trip begin.  Now that my setup is stable, is there a reason to update?  What's new?

@captainkw - commit log for those updates here. Biggest change was turning off the GPS LED for night ops.


Hotfix/fix null reference exception thrown when api parameter description.model metadata is null

Looks like you ran into an issue and jump straight into fixing it. Thanks. Can you elaborate on the issue you encountered?
As I recall, the only other time I've seen an issue like this happen is when there is a route template parameter that isn't defined in any bound model. For example, when defined in a URL segment, the "API version" route parameter isn't defined as a formal parameter or part of a model anywhere. I had to add some special handling to deal with it.
I'd prefer not to have null because that cause it's own set of other issues. However, there may not be any other reasonable alternatives.

@commonsensesoftware
Just like you said. I encountered the same issue.
There were several APIs adopting a same routing hierarchy, sharing some route parameters that may not defined as the formal functional parameters on some API methods.

I see. Is there any way we can provide a default model? Even without other information, any route parameter can be treated as a string. I'll research this a bit as well. If we can't come up with any alternatives, then we may have to go with this solution. Thanks.

@commonsensesoftware
Sorry I don’t follow what you said about “a default model”. Can you please explain it?

The model metadata for the parameter is unresolved in some cases, which is resulting in null. This only seems to happen for route parameters that are not formal parameters or part of a model. Such parameter should safely be able to be model as string. If we can represent the parameter with a name and as type string this would be preferable to null.

@commonsensesoftware
Sorry for the late response! And thanks a lot for the detailed explanation!
It seems like there were some misunderstanding, and sorry again I didn't make myself clear.
I've known the reason why the NullException happened.When I asked if you could explain it, I actually wanted an example from you.
Anyway, I guess I get the idea of "a default model", which should be preparing a base class(model) with all parameters in the route and creating sub classes as request entity model for every API method. It's just I don't think this "a default model" is a flexible way to solve this problem.

Hey @will-beta, sorry for the hiatus, been busy with the day job lately. I'm trying to circle back around on this PR. I see that you've added a bunch of defensive things to handle null. I'd like to avoid null all together if possible. Do you have a repro or some sample scenario that causes this issue (e.g. nulls)? I'd like a better understanding of the scenario. Feel free to attach the *.zip here or provide a link to a source repo.
In early versions of this package, I think nulls may have been possible, but I thought I addressed all the cases where that could happen. Maybe I'm miss understanding and this is just some defensive code for things the API Explorer cannot do on its own. For example, it will handle the API version route parameter even though it's not model-bound, but that's not true for other route parameters that are not model-bound and are not known to API versioning. I'd be ok adding the checks to the examples of illustrative purposes, but these shouldn't be necessary in the API Explorer code itself.
If things are running into NRE directly in the API Explorer code, I'd like to:

Know what conditions or setup require that to happen
Know where the NRE happens in the code
Add tests that ensure it's properly handled when null is encountered

Thanks


Added webmap feature with Contextily module

Added the contextily module to be used for downloading web tiles and using them for basemaps.
The feature uses the bounds of the GeoDataFrame or GeoSeries object supplied by the user, as well as a parameter for specifying the web tiles URL.
The webmap parameter should evaluate to one of the URLs in the contextily/tile_providers.py file.
For now, the feature should only work correctly for plotting in the Mercator projection, as the tiles come in EPSG:3857 (Web Mercator).
The API is:
gplt.polyplot(df, projection=gcrs.Mercator(), webmap="OSM_A")
It passed the tests but it has behaved strangely in my computer, especially the calls to the dictionary keys or variables from contextily/tile_providers.py (which the interpreter signals as a NameError for some reason). For now I have only supplied the feature code to the polyplot class. It should be trivial to add it to the other functions, as soon as I can get it working properly.
The zorder parameter in the ax.imshow() call is because the tile image should be used in the background as a basemap.
This pull request is mainly to show what I have done so far and the basic idea behind the code.
Please, I will welcome any suggestions about the code.

Toying with this on my local machine now.
In terms of API, the parameterization looks good.
We should have simply gplt.polyplot(df, webmap="OSM_A") work as well, raising a warning telling the user that specifying a webmap parameter forces the Mercator projection.
Additionally we will need to add a component raising an error when the user specifies both a webmap and a non-Mercator projection.
Since this is going to apply to all of the plot types, later on we will want to consolidate all of the new methodology in a new method or handful of methods. Not yet, but an FYI for later.
You state that "The feature uses the bounds of the GeoDataFrame or GeoSeries object supplied by the user". What will happen if the user uses a pattern where they reuse the axis? E.g. over-plotting a pointplot (potentially one with radically different boundaries) over a polyplot. We should figure out what we can do in this case.
Now, with the output. I've cloned this feature and specified the following minimal example:
import pandas as pd
from quilt.data.ResidentMario import geoplot_data
import geopandas as gpd
%matplotlib inline

boroughs = gpd.read_file(geoplot_data.nyc_boroughs())

import geoplot as gplt
import geoplot.crs as gcrs

gplt.polyplot(boroughs, projection=gcrs.Mercator(), webmap="OSM_A")

However, I'm not getting the intended output. =( Does this example work for you?

Closing as stale. This feature is on the near-term roadmap.


ASP.net Core Integration Tests

We need a better test set for our middleware. Ideally we should create a bigger schema in a library that we can use in the various test projects.

This one is done now .... we are using the Star Wars schema for testing


[Proposal] Become a Deno first library

Today, this library is developed in Node.js and configured to support Deno.
I propose that it's migrated to be developed in Deno and configured to support Node.js.
I realise this is an intimidating idea, but I believe you could have the same (if not better) output and a much better contributor experience.
Why is Deno a good fit for Valibot?
Aligned Philosophy

Both Deno and Valibot believe in decomposing code into small modules so users can just depend on what they need
Both Deno and Valibot care about browser/web compatibility
Both Deno and Valibot care about strict TypeScript type safety
Both Deno and Valibot care about developer experience

Tooling Simplicity
In order to get typescript, tests, linting, and formatting you are using 9 direct dependencies from 4+ different teams totalling 117MB. These dependencies all require a bunch of different configs:

tsbuild.json
prettier.config.cjs
.prettierignore
package.json
vite.config.ts
.eslintrc.cjs

Deno has all of this functionality baked into the deno binary, managed by one team. Since it uses very sensible defaults you only need very little config and it all lives inside deno.json. Pulling in the Deno packages bdd + expect can provide a more familiar testing experience for only an extra ~85KB. While dev dependency size isn't an important metric in itself, it's a good indicator of how much complexity you're depending on.
Testing Across Runtimes
Vitest does not work on Deno today, this makes it hard to run the same tests across both runtimes. If the library migrates to Deno.test and uses dnt for Node.js compatibility then dnt automatically runs the tests in the Node.js runtime with full compatibility.
Cons, Risks, and Unknowns

Expect Compact: There is no native deno library that supports expect.any so we would need to either continue using npm:expect or refactor the tests so they don't use comparable.ts
Deno as a barrier to contribution: More potential contributors will have a Node.js setup. It doesn't take long to install Deno and the vs-code extension, but it might deter some people.
No deno bundler: Deno doesn't have any built-in bundle tooling and dnt doesn't minify, so either keep tsup or look for an alternative.
tsup + dnt compact: It looks like dnt (the primary deno to npm converter) restructures the output a bit, it might need a bit of tweaking to keep backwards compact. Tsup could then run on the Node.js esm output from dnt.

End note
No pressure on any of this. I think it's a cool opportunity but I can see you have a lot on. I've thrown together a PoC in my fork: https://github.com/syhol/valibot/pull/2 and I've got it building but it needs tsup integration and tidy ups.

Thank you for all the details. It is interesting, I was thinking about migrating to Bun but I was not sure if that is a bad idea for all Windows contributors. I'll keep this issue in mind, but don't expect a quick reaction. I think it a good way to get feedback and discuss about it here with more people.

I think it's a bad idea to make Valibot an <any JS runtime>-first library. Instead, modernisation should be done in a runtime-agnostic way.
Bun is also a viable modern runtime, and Node also gained native TS import support in latest versions. Neither Bun nor Deno support Vitest. One can think they do it intentionally to force users to use their built-in test libraries, which locks the project into their ecosystem.
I recommend replacing Prettier with Biome, which is a runtime-agnostic eslint-compatible linter, prettier-compatible formatter and it also has an import sorter. Plus, it's a lot faster than prettier/eslint, because it's written in Rust. It also provides fast LSP-based editor integration.

I think it's a bad idea to make Valibot an -first library

When I wrote this issue Node didn't properly support ESM and Bun didn't recommend using file extensions with ESM. So at the time Deno seemed to most align with what Fabian was doing with modular design and browser http imports.
Since then Bun/Node/Deno have converged more and more, and browser http imports seem to have gone out of fashion before they ever took off. This Deno proposal isn't as relevant today.

Neither Bun nor Deno support Vitest

bun run test passes 100% and deno run test passes 95% with just one issue that causes about 5% of the tests to fail. So not perfect but it is technically supported and they are fixing issues as they find them.

One can think they do it intentionally to force users to use their built-in test libraries, which locks the project into their ecosystem.

I doubt it. vitest and jest do/did some pretty gnarly stuff depending on some very specific nodejs systems and it's taken a long time for deno/bun to support them. Deno 2.0 and JSR has thrown out so much of its original USP because they really want drop-in compatibility with the node ecosystem. The built-in testing exists for the "it just works" selling point, especially because jest and typescript were so annoying to get working together.

I recommend replacing Prettier with Biome

Yeah, if you won't move to Deno I would definitely agree. Biome was only 1 month old when I wrote this issue 😁

Hey everyone, thanks for your feedback. At the moment the library source code is more important than our development setup, but I will keep an eye on the ecosystem and improve our setup from time to time. I have started using Deno for scripting in other projects and am curious to see where things go at VoidZero.


Refresh bindings when OAuth2 process is complete

Summary
This PR adds a new endpoint for Apps to call when they want to refresh a specific user's bindings.
POST /api/v1/refresh_bindings?user_id=(some_user_id)
This PR dispatches the refresh_bindings websocket message when an OAuth2 connect process is complete.
This fix requires no changes to webapp, server, or mobile. The ServiceNow and Zendesk apps do not need to be updated either.
Ticket Link
Fixes https://mattermost.atlassian.net/browse/MM-35076
Related Pull Requests
https://github.com/mattermost/mattermost-app-servicenow/pull/22

Codecov Report

Merging #158 (61faa03) into master (a8104b4) will decrease coverage by 0.03%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master     #158      +/-   ##
==========================================
- Coverage   20.46%   20.43%   -0.04%
==========================================
  Files          29       29
  Lines        1324     1326       +2
==========================================
  Hits          271      271
- Misses       1035     1037       +2
  Partials       18       18

Impacted Files
Coverage Δ

server/proxy/bindings.go
84.81% <0.00%> (-1.09%)
:arrow_down:

server/proxy/enable.go
4.87% <0.00%> (ø)

server/proxy/install.go
0.00% <0.00%> (ø)

server/proxy/oauth2.go
0.00% <0.00%> (ø)

server/proxy/uninstall.go
0.00% <0.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 a8104b4...61faa03. Read the comment docs.

I'm not sure where docs should go for this, but something like this would suffice.

When the OAuth2 process for connecting to an external service completes, the user will receive a websocket message that automatically refresh their bindings. There is currently no support for refreshing the bindings when disconnecting from the external service.

@mickmister The docs should go to https://developers.mattermost.com/integrate/apps/using-third-party-api/

/update-branch


Remove pip-tools support

uv has now been the default for a while and folks have contributed more functionality around it.

Would you be able to add me as a collaborator. I already have a fork so am not able to create another

Yeah, that's roughly what I was imagining. Can you just create a PR from a non-main branch in your existing fork? That would be the easier solution.

Yeah, that's roughly what I was imagining. Can you just create a PR from a non-main branch in your existing fork? That would be the easier solution.

I'll try that

@charliermarsh here's a first cut, but without any docs updates https://github.com/astral-sh/rye/pull/1226


Visualize license finding curations

License finding curations have been introduced in context of #1726.
The implementation currently uses the curations to correct the detected licenses whereas in the reports only the corrected detected licenses are visible.
The curations should be made visible somehow.
Ideas for use cases to consider

Verifying / reviewing the whole report
Verifying / reviewing / seeing the effect of a single curation

To show applied license finding curations in the web app reporter they need to be added to the evaluated model. Currently the EvaluatedFinding only contains applied path excludes:
https://github.com/oss-review-toolkit/ort/blob/main/reporter/src/main/kotlin/reporters/evaluatedmodel/EvaluatedFinding.kt

Closed as part of backlog grooming. Feel free to comment if you would like to contribute to this.


SqlPersistT MonadThrow, MonadCatch, MonadMask instances?

Do you mean SqlQueryT? Yes, we can add those instances. The instances shouldnt be added for SqlTransaction, though, because of the retry logic in it.
PR welcome!

The instances shouldnt be added for SqlTransaction, though, because of the retry logic in it.
Can you please elaborate?

So the whole point of SqlTransaction is that it contains actions running within a single transaction. But some databases (e.g. postgres) require you to retry transactions if it fails, which is why you can specify retry logic in runSqlQueryTWith.
So imagine if you run
withTransaction $ m1 `finally` m2

and postgres throws an error in m1 that tells you you need to rerun the transaction. In this code block, m2 would try to run (and throw the error again if it does any db actions). If m2 is a noop like return () then it would swallow the retry error and prevent the retry logic from happening.
I'm pretty sure there are other Bad Things that can happen too. But do you actually need MonadCatch/MonadMask on SqlTransaction? If you add the instances to SqlQueryT, it should handle most use cases; it just wouldnt support running MonadCatch code in withTransaction


Can the server be deployed with high availability?

Currently, helm-chart only supports the deployment of a single server. Can multiple servers be deployed to achieve high availability?
https://www.jetbrains.com/help/teamcity/2024.07/multinode-setup.html?TeamCity Documentation

Hi, thank you for this information. I've been using TeamCity for more than six years and thought it was a single-daemon setup.
Yes, it makes sense to set it up as a high-availability solution... 👍

Will this helm-chart support high-availability deployment in the future?This is the only official helm I've found.
I found another helm-chart that supports HA, but it's not very active and, you know, unofficial.
https://artifacthub.io/packages/helm/teamcity-server/teamcity-server

Yes, I will add it to my list to implement. I have just one concern – it uses a shared folder between daemons, which could be a single point of failure. I don’t recall any downtime with TS, except during the upgrade process.
My chart is also unofficial, I do not work at jetbrains...

Hi,
My first idea was to use first pod-0 to the humans requests (ingress), all others for the workers.
But if you have a better idea, I'm open to suggestions.
TeamCity ha currently implemented as an alpha version. There are many things to improve here )


Service-defined durations, DLKT scheduling, and launch.json – MERGE AFTER FAIZ'S SANITY TESTING

Added example launch.json for vscode. Improved with compound to launch
all at once.  And --reload for Python to watch files.
Update gitignore adding virtualenv
Add optional timeslot_duration field on Service, use it when
calculating available times.
Appointment-frontend passes in Service ID for service defined
durations
Model DLKT in office and service, include in admin panel
Scheduling (and submitting) of service defined durations
Scheduliing of adjacent short appointments working (830-840, 840-850)
DLKT parallel scheduling working, both use "no_of_slots" field for frontend

Closing.
This branch has been merged into https://github.com/acoard-aot/queue-management/pull/43
Once https://github.com/acoard-aot/queue-management/pull/43 is merged in, the DLKT work will be merged as well.
This is necessary as both features use migrations which rely on each other.


Add credo and dialyzer

Resolves https://github.com/zorn/franklin/issues/42
Although not in the original issue, I added dialyzer for more robust static analysis (which pointed out some missing typespecs). 😅

Thanks so much for contributing this. I'll take a look at it tomorrow.

Okay, so I ended up scrapping the explicit MIX_ENV=test in the CI config for now. Every command will use dev as normal except for mix test at the end of the CI job.
The two caching steps for _build/deps will still apply, but now both dev and test will be cached. In the long run I don't think this will be a problem. It is essentially doubling the amount of cached artifacts, but neither is super huge.


Feat/xd 82

Pull request for the #82

I am not sure. These changes were all done by Jonas in the #110 branch. I just branched of feat/xd-110 because the timeseries stuff works there. Maybe I should have created the PR after the 110 branch is merged.

I am not sure. These changes were all done by Jonas in the #110 branch. I just branched of feat/xd-110 because the timeseries stuff works there. Maybe I should have created the PR after the 110 branch is merged.

Did you merge or rebase? But yeah ur right theres a lot from jonas branch

No it is all from Jonas I did not change anything yet. I just created a PR because then I can see the changes and if tests run and everything better before I put my stuff there. Where I work we always create the PR and the feature branch at the same time and then start to work on it

Jonas told me that I should put the PR as draft in these situation so I put it to draft


force migration to newer gfortran on windows

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe/meta.yaml:

No valid build backend found for Python recipe for package pyfabm using pip. Python recipes using pip need to explicitly specify a build backend in the host section. If your recipe has built with only pip in the host section in the past, you likely should add setuptools to the host section of your recipe.

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

Hi! This is the friendly automated conda-forge-webservice.
I tried to rerender for you, but it looks like there was nothing to do.
This message was generated by GitHub actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/11231925615.

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-webservice.
I tried to rerender for you, but it looks like there was nothing to do.
This message was generated by GitHub actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/11232190428.


[Bug]: UI is one state change behind

Current Behavior
Using the fan card, if I change the state, it takes about 5-15 seconds to update. I can force it to update quicker by changing the state again, but it lags one state change behind.
Eg. If I set the speed to 20% it will take about 5-15 seconds to update and go green. If I then quickly set it to 40%, I can see it go green and move to 20%. Then it about 5-15 seconds it will change to 40%.
Expected Behavior
The mushroom card should reflect the current state near instantly.
Steps To Reproduce
No response
Environment
OS: Ubuntu 20.04
Brower: chrome
Version: 2.1.3
Hassio: 20226.7

Anything else?
Similar to https://github.com/piitaya/lovelace-mushroom/issues/539

Did you test with other non-mushroom card ?

Looking into this a bit more, it might be a conflict with the theme I am using - Dwains Theme. I used the mushroom fan card in the base HA theme and its working fine. Not sure why its playing up in Dwains Theme

I never had issue with mine.

I kinda have the same issue with lights, using ZHA.
when I toggle a group of lights, dim it or change the color, it doesn’t change in the UI until I do it again 1-5 times. Not quite sure how it syncs up with the actual state of the devices, if there might be a slight 1 second delay (eg. Light transition time or whatever).
but it’s really annoying, because I really like this theme/cards. But there’s something not functioning as is should.

I kinda have the same issue with lights, using ZHA.
when I toggle a group of lights, dim it or change the color, it doesn’t change in the UI until I do it again 1-5 times. Not quite sure how it syncs up with the actual state of the devices, if there might be a slight 1 second delay (eg. Light transition time or whatever).
but it’s really annoying, because I really like this theme/cards. But there’s something not functioning as is should.

Possibly the same issue: when I use the mushroom climate card to change the temp, takes about 1-2 secs for the number to be updated. If I use the generic climate card to do the same it updates instantly. I assume this is just reflecting the number in the card instantly rather than confirming it has been actioned, but I think the user experience is worse with the delay.


Use lifecycle hook in media content elements

REDMINE-17592

Coverage remained the same at 99.208% when pulling 093fcc32cb266fbe6b062d722e4bf230a277687a on tf:lazy-inline-media into 568700e232331cc93a45ea39903f17faa84d04e4 on codevise:master.


bug fixed running: send empty string instead of null

What type of PR is this?

[x] Bug Fix

Hi, your name is not showing up in the contributors. I guess its because email and name in your terminal is not configured or the email in your GitHub account is different from the one set in terminal.
Maybe try running git config --global user.email and see what email id it outputs and then set/add that email id in GitHub from https://github.com/settings/emails


[PIL-1097][SM]Verify BTN return submission KB page on Organisation an…

Added test for BTN return submission KB page on Organisation and Agent User journeys

Code formatting is needed.


SearchBar Add vaults search capability

What would you like to be added:
Allow the searching of vaults.
Note
Vaults share the same ID as the Transaction used to create it. Hence, both Transaction and Vault need to be shown in the search results.
Part of #450
/triage accepted

Closed with PR #498


To know sheduled process time and business rules

Hello
Its really nice to play with tm1py
I want to know how can we know which processes are sheduled with their time?
and also can we get the business rules directly which are used for cube?
Thanks is advance

from TM1py.Services import TM1Service

with TM1Service(address='localhost', port=12354, user='admin', password='apple', ssl=True) as tm1:
    chores = tm1.chores.get_all()
    for chore in chores:
        print("Chore: {}, Starttime: {}, Active: {}".format(chore.name, chore.start_time, chore.active))
        for p, task in enumerate(chore.tasks):
            print("{}. Process: {}, Parameters: {}".format(p+1, task.process_name, task.parameters))

    cubes = tm1.cubes.get_all()
    for cube in cubes:
        print("Cube: {}, Rules: {}".format(cube.name, cube.rules))


Provide an API to constify enum variants.

r? @upsuper

A question: may I do
///

eCSSProperty_COUNT,

rather than adding it after? I'm concerned about exceeding 80 chars limitation in Gecko code...
Also, is it possible to apply

 to enum item? I think we don't really need the dummy ones at all.

I don't think you can do that because doxygen thinks that kind of comment is a comment for the whole enum and applies them to every following item.
I've added a programmatic API that you could also use from the build script though (see the type_chooser API).

Regarding hide, yeah, we should be able to handle that quite easily, let me move some code around :)

I guess you can change constify_enum_variant to a more general method and let it return the action for a given enum item?

Heh, was writing that right now :)
What do you think about the last commit?

Looking at the (previously) last commit, I wonder do we really need to try that hard to add enum variant? I don't see much usefulness from doing so.
I think we can simply not add constified items to enum variants, which should simplify the code logic.

 I suddently realize that you have to add enum variant anyway, because otherwise that constant wouldn't be referring to an enum variant.

@upsuper consider the following:
enum Foo {
    A = 1,
    B = 10, /**<

 */
};

If I do that (avoid adding constified items), two things happen.
First, they wouldn't have same type (we'd need to make the const an integer or whatever). Second, rust's optimizations may kick in with disastrous consequences (a la #225).
We could enforce constant to be just used when other enum values are around, but seemed easy enough to support the general case.

Oh, didn't read your other comment (had my browser window open).

:pushpin: Commit fee7e96 has been approved by upsuper

Nice catches :)
@bors-servo r=upsuper

:hourglass: Testing commit fee7e96 with merge 6bfeae1...

:sunny: Test successful - status-travis


Inquiry about Windows support for examining network traffic tutorial

Hello guys,
I was going through the Examining network traffic tutorial and I was wondering if this tutorial is supported on Windows. The tutorial mentions the use of tcpdump, which to my knowledge is not available on Windows.
Is there an alternative method or tool recommended for Windows users to follow this tutorial? Any guidance or additional documentation on this would be highly appreciated.
Thank you for maintaining the documentation and for your support!
Best regards,
Yucheng Song

Yeah, this one is very Linux-specific.  We should probably put a note at the top saying that.

Hi, @clalancette,
Could you please help put this note?
I appreciate your help very much in advance!


Fix:#309 4 Cancel toast on finish

PR addressing #309 4

Automated message from Dropbox CLA bot
@vishwesh3, it looks like you've already signed the Dropbox CLA. Thanks!

@vishwesh3 Nice, the code looks good to me :+1:

Merged, thanks @vishwesh3 and @Sam1301!  Also edited the commit message to avoid closing #309 since it's not done yet.


issue with too many subdomain levels

Welcome!

[X] Yes, I've searched similar issues on GitHub and didn't find any.
[X] Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What did you do?
using traefik 2.5 on docker with letsencrypt configured correctly with DNS validation for wildcards.
traefik has sucessfully obtained a cert for *.example.com and uses it correctly when I go to gitlab.example.com
now it doesn't work for sub-subdomains, so traefik correctly obtained a letsencrypt cert for pages.gitlab.example.com
My issue is now that it's applying the traefik default cert when I go to myproject.pages.gitlab.example.com
I waited a bit just to see if opbtaining the cert was taking some time but no, it's not coming, and I see no issue in the traefik.log
I have one gitlab container only but lots of labels on it :
    labels:
      traefik.http.routers.gitlab.service: gitlab
      traefik.http.routers.gitlab.rule: Host(`gitlab.example.com`,`gitlab.example.de`)
      traefik.http.services.gitlab.loadbalancer.server.port: 80
      traefik.http.services.gitlab.loadBalancer.server.scheme: http
      traefik.http.routers.gitlab-prometheus.rule: Host(`prometheus.gitlab.example.com`,`prometheus.gitlab.example.de`)
      traefik.http.routers.gitlab-prometheus.service: gitlab-prometheus
      traefik.http.services.gitlab-prometheus.loadbalancer.server.port: 9090
      traefik.http.services.gitlab-prometheus.loadBalancer.server.scheme: http
      traefik.http.routers.gitlab-registry.rule: Host(`registry.gitlab.example.com`,`registry.gitlab.example.de`)
      traefik.http.routers.gitlab-registry.service: gitlab-registry
      traefik.http.services.gitlab-registry.loadbalancer.server.port: 8123
      traefik.http.services.gitlab-registry.loadBalancer.server.scheme: http
      traefik.http.routers.gitlab-pages.service: "gitlab-pages"
      traefik.http.routers.gitlab-pages.rule: "Host(`pages.gitlab.example.com`,`pages.gitlab.example.de`) || HostRegexp(`{subdomain:[a-z]+}.pages.gitlab.example.de`) || HostRegexp(`{subdomain:[a-z]+}.pages.gitlab.example.com`)"
      traefik.http.services.gitlab-pages.loadbalancer.server.port: "8081"
      traefik.http.services.gitlab-pages.loadbalancer.server.scheme: http
      traefik.http.routers.gitlab-mattermost.rule: Host(`mattermost.example.com`,`mattermost.example.de`)
      traefik.http.routers.gitlab-mattermost.service: gitlab-mattermost
      traefik.http.services.gitlab-mattermost.loadbalancer.server.port: 8124
      traefik.http.services.gitlab-mattermost.loadBalancer.server.scheme: http

I did setup letsencrypt a while ago so I'm not even sure how I got it to request *.example.com, idealy, I'd like traefik to find out that it needs to get *.pages.gitlab.example.com but I'd settle for it requesting on the fly for the FQDN as I'm not expecting many possible urls for my pages it's a small gitlab instance.
I even tried adding traefik.http.routers.gitlab-pages.tls.domains.main: "*.pages.gitlab.example.com" but no luck.
Am I trying to do something not allowed or have I found an issue ?
What did you see instead?
myproject.pages.gitlab.example.com gets served sucessfully by traefik but using the default self-signed certificate instead of getting a valid cert from letsencrypt
What version of Traefik are you using?
Version:      2.5.5
Codename:     brie
Go version:   go1.17.5
Built:        2021-12-10T17:00:35Z
OS/Arch:      linux/amd64
What is your environment & configuration?
docker provider
If applicable, please paste the log output in DEBUG level
No response

Hello @toxic0berliner,
Thanks for your interest in Traefik!
According to rfc 2818:

Matching is performed using the matching rules specified by
[RFC2459].  If more than one identity of a given type is present in
the certificate (e.g., more than one dNSName name, a match in any one
of the set is considered acceptable.) Names may contain the wildcard
character * which is considered to match any single domain name
component or component fragment. E.g., .a.com matches foo.a.com but
not bar.foo.a.com. f.com matches foo.com but not bar.com.

Thus, your cert *.example.com can match gitlab.example.com but not pages.gitlab.example.com.

I'm sorry I think I've not made myself clear.
I indeed fully expected that my *.example.com cert would not at all be valid for pages.gitlab.example.com and much less *.pages.gitlab.example.com.
This is why it's not a surprise to me that traefik decided to get a dedicated pages.gitlab.example.com cert, and indeed it sucessfully obtained it.
What I'm wondering @tomMoulard  if you allow me is if there is a way for me to tell traefik to request a cert for *.pages.gitlab.example.com, but I think this is indeed more a help request than a bug and is probably more destined for the community forums.
But in this ticket, I still feel it is not normal that when a client is acessing somerepo.pages.gitlab.example.com it gets served the default cert. I fully expect traefik has the capability to obtain a cert for each and every something.pages.gitlab.example.com that my users might choose to access, and it should get a dedicated cert each time a request is made I think.
With the above label traefik.http.routers.gitlab-pages.tls.domains.main: "*.pages.gitlab.example.com" I think it is indeed a bug that traefik is not trying to get such a wildcard cert.

Well, even if I think given the rule traefik could and hould have found it out, I was able to enforce it using information from here https://doc.traefik.io/traefik/https/acme/#domain-definition
The key was to add tls=true to the router :
      traefik.http.routers.gitlab-pages.service: "gitlab-pages"
      traefik.http.routers.gitlab-pages.rule: "Host(`pages.gitlab.example.com`) || HostRegexp(`{subdomain:[a-z]+}.pages.gitlab.example.com`)"
      traefik.http.routers.gitlab-pages.tls: true
      traefik.http.routers.gitlab-pages.tls.certresolver: le
      traefik.http.routers.gitlab-pages.tls.domains[0].main: "pages.gitlab.example.com"
      traefik.http.routers.gitlab-pages.tls.domains[0].sans: "*.pages.gitlab.example.com"


did not start with actual node lts

Hi Guys,
I updated my homebridge today incl. the node version.
node.js 14.15.0
npm 6.14.8
after a reboot the homebridge-mi-flora-filtered plug-in did not start proper and the complete homebridge shutdown.
Nov 10 21:36:37 raspberrypi homebridge[9515]: [10/11/2020, 21:36:37] ERROR LOADING PLUGIN homebridge-mi-flora-filtered: Nov 10 21:36:38 raspberrypi homebridge[9515]: [10/11/2020, 21:36:38] Error: The module<EMAIL_ADDRESS>Nov 10 21:36:38 raspberrypi homebridge[9515]: was compiled against a different Node.js version using Nov 10 21:36:38 raspberrypi homebridge[9515]: NODE_MODULE_VERSION 72. This version of Node.js requires Nov 10 21:36:38 raspberrypi homebridge[9515]: NODE_MODULE_VERSION 83. Please try re-compiling or re-installing Nov 10 21:36:38 raspberrypi homebridge[9515]: the module (for instance, using npm rebuildornpm install). Nov 10 21:36:38 raspberrypi homebridge[9515]:     at Object.Module._extensions..node (internal/modules/cjs/loader.js:1122:18) Nov 10 21:36:38 raspberrypi homebridge[9515]:     at Module.load (internal/modules/cjs/loader.js:928:32) Nov 10 21:36:38 raspberrypi homebridge[9515]:     at Function.Module._load (internal/modules/cjs/loader.js:769:14) Nov 10 21:36:38 raspberrypi homebridge[9515]:     at Module.require (internal/modules/cjs/loader.js:952:19) Nov 10 21:36:38 raspberrypi homebridge[9515]:     at require (internal/modules/cjs/helpers.js:88:18) Nov 10 21:36:38 raspberrypi homebridge[9515]:     at Object.<anonymous> (/usr/local/lib/node_modules/homebridge-mi-flora-filtered/node_modules/@abandonware/bluetooth-hci-socket/lib/native.js:6:15) Nov 10 21:36:38 raspberrypi homebridge[9515]:     at Module._compile (internal/modules/cjs/loader.js:1063:30) Nov 10 21:36:38 raspberrypi homebridge[9515]:     at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10) Nov 10 21:36:38 raspberrypi homebridge[9515]:     at Module.load (internal/modules/cjs/loader.js:928:32) Nov 10 21:36:38 raspberrypi homebridge[9515]:     at Function.Module._load (internal/modules/cjs/loader.js:769:14)
I tried out again
sudo npm install --unsafe-perm -g bluetooth-hci-socket sudo npm install -g --unsafe-perm @abandonware/noble sudo npm install -g --unsafe-perm node-gyp
but this didnt help.
Have anybode a tipp, please?
Currently I remove the entry in the config.json and the homebridge restart again, but without the xiaomi sensons of course.
Thank you!

I solved the problem for me today.
I removed the xiaomi from config. removed the plug-in.
used apt-get update & upgrade. re-installed the xiaomi plugin again and enter the config.
Restart and it works!


Feature Request: Supporting rxjava observables with Rxjava Schedulers

So far, the tracer's context is lost when using DeferredResult+Observable+Schedulers. It'd be nice to have this supported out of the box with spring-sleuth. Looking at the example here: http://blog.mabn.pl/2014/11/rxjava-logback-and-mdc-threadlocal.html, a RxJavaSchedulersHook can be created (and registered as an RxJava Plugin) and sleuth related variables can be copied over to the newly created thread.

Pull requests are more then welcome :)

@marcingrzejszczak I will give it a go. Would you be able to point me in the direction of which threadlocal variables specific to sleuth need to be copied over?

Sure!
There are the SpanInjector and SpanExtractor interfaces that will help you with that. Let's take a look at https://github.com/spring-cloud/spring-cloud-sleuth/blob/master/spring-cloud-sleuth-core/src/main/java/org/springframework/cloud/sleuth/instrument/web/client/HttpRequestInjector.java .
One passing tracing information FROM Sleuth to SOMETHING we're using a SpanInjector. It means that we will leave Sleuth and get outside the process most likely (but no necessarily). In that example you can see that from a Span we're putting information to a HttpRequest. You can see which information is important for us. All the header names are there in the Span class as static constants.
If you want to get information from SOMETHING and build a Span then you're using the SpanExtractor. Example for messaging - https://github.com/spring-cloud/spring-cloud-sleuth/blob/master/spring-cloud-sleuth-core/src/main/java/org/springframework/cloud/sleuth/instrument/messaging/MessagingSpanExtractor.java . As you can see from a carrier (Message / HttpRequest etc.) that has the tracing information we will build a Span - by means of a Span.builder().
Don't hesitate to ping me here or on Gitter in case of any further questions https://gitter.im/spring-cloud/spring-cloud-sleuth?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge

@marcingrzejszczak :point_up_2:

@marcingrzejszczak I have pushed the code changes to my own fork (for now, no PR yet). You can find the code here:
https://github.com/shivangshah/spring-cloud-sleuth/commit/b5bf395531a3bd6f234096a8dc5f4a6d004d388b
Let me know what you think. The unit testcases look ok (I think), but I wonder if there needs to any integration test cases? I didn't see any for HystrixConcurrencyStrategy.

I'll take a look at that tomorrow - the integration tests are everywhere else cause by default the SeltuhHystrixConcurrencyStrategy gets registered in each context in every integration test


Add continuous integration

This is the continuation of #19

[x] Run rust compilation
[x] JS lint and prettier checks
[x] JS unit tests

OH thank you I'll take alook at it


Terragrunt & GCS credentials

We just tried to setup Terragrunt with GCS remote state using a configuration like:
remote_state {
 backend = "gcs"
 config = {
   bucket = "tf"
   credentials = "${path_relative_from_include()}/gcp-infra-services.json"
   prefix = "${path_relative_to_include()}/terraform.tfstate"
 }
}

and got an error from Terragrunt saying something about "Application Default Credentials" and a link to GCP docs (sorry for the vagueness, don't have that error in front of me right now). By reading the doc by the link we learned about env var GOOGLE_APPLICATION_CREDENTIALS and when we set it pointing to GCP credentials file it worked (the credentials file had all the permissions necessary).
To the best of our understanding, Terragrunt tries to verify if GCS bucket exists and create one if it doesn't. Also, it seems that the idea is that credentials Terragrunt would use will be different from credentials passed to the Terrraform backend for the purpose of "separation of concerns".
All of this is really great with the only exception that it doesn't work in our environment. :)
The few questions that we have in mind that we weren't able to figure out from the docs are:

what are the alternatives to provide Terragrunt credentials to check/create GCS bucket?
if GOOGLE_APPLICATION_CREDENTIALS env var is the only one - could Terragrunt be smart and attempt to do that only if credentials set and just skip this otherwise?
lastly, is it possible to tell Terragrunt explicitly to not attempt to do that and just configure the Terraform backend as is?

In our case, we ended up with the following workaround instead but it would really be nice if we could use the remote_state instead:
terraform {
  extra_arguments "backend" {
    commands  = ["init"]

    arguments = [
      "-backend-config=credentials=${path_relative_from_include()}/gcp-infra-services.json",
      "-backend-config=bucket=tf",
      "-backend-config=prefix=${path_relative_to_include()}/terraform.tfstate",
    ]
  }
}

Thanks!

@robmorgan You worked with the GCS backend recently. Think you could check this out?

and got an error from Terragrunt saying something about "Application Default Credentials" and a link to GCP docs (sorry for the vagueness, don't have that error in front of me right now).
@ashald would be helpful if you could provide the detailed error message

@autero1 I’ll post it alter today. Frankly I’m not sure if it’s important at all as there seems to be a different problem: Terragrunt would need some kind of credentials even to check if GCS bucket exists (let alone create it) and as long as there is no way to disable this behavior some kind of an issue is inevitable if those credentials are not provided.
P.S.: Pardon me if my doc-reading skills are at fault but I wasn’t able to find anything in Terragrunt docs about authentication for gcs.

We just introduced the ability to disable the auto initialization of the backend in v0.19.7. Would this feature help with your use case? Here are the docs for it:

Note: You can disable automatic remote state initialization by setting remote_state.disable_init, this will skip the automatic creation of remote state resources and will execute terraform init passing the backend=false option. This can be handy when running commands such as validate-all as part of a CI process where you do not want to initialize remote state.

The detailed error message I mentioned previously:
$ TERRAGRUNT_DEBUG=1 terragrunt plan-all
[terragrunt] [/home/user1/tg-gcp] 2019/07/10 20:25:32 Running command: terraform --version
[terragrunt] 2019/07/10 20:25:32 Setting download directory for module /home/user1/tg-gcp to /home/user1/tg-gcp/.terragrunt-cache
[terragrunt] 2019/07/10 20:25:32 Module /home/user1/tg-gcp does not have an associated terraform configuration and will be skipped.
[terragrunt] 2019/07/10 20:25:32 Setting download directory for module /home/user1/tg-gcp/prod/step001 to /home/user1/tg-gcp/prod/step001/.terragrunt-cache
[terragrunt] 2019/07/10 20:25:32 Stack at /home/user1/tg-gcp:
  => Module /home/user1/tg-gcp/prod/step001 (excluded: false, dependencies: [])
[terragrunt] [/home/user1/tg-gcp/prod/step001] 2019/07/10 20:25:32 Module /home/user1/tg-gcp/prod/step001 must wait for 0 dependencies to finish
[terragrunt] [/home/user1/tg-gcp/prod/step001] 2019/07/10 20:25:32 Running module /home/user1/tg-gcp/prod/step001 now
[terragrunt] [/home/user1/tg-gcp/prod/step001] 2019/07/10 20:25:32 Reading Terragrunt config file at /home/user1/tg-gcp/prod/step001/terragrunt.hcl
[terragrunt] [/home/user1/tg-gcp/prod/step001] 2019/07/10 20:25:32 Module /home/user1/tg-gcp/prod/step001 has finished with an error: dialing: google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.
[terragrunt] 2019/07/10 20:25:33 configstack.MultiError Encountered the following errors:
dialing: google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.
/go/src/github.com/gruntwork-io/terragrunt/configstack/running_module.go:179 (0xcbc094)
/go/src/github.com/gruntwork-io/terragrunt/configstack/running_module.go:163 (0xcbbe56)
/go/src/github.com/gruntwork-io/terragrunt/configstack/running_module.go:62 (0xcbb21d)
/go/src/github.com/gruntwork-io/terragrunt/configstack/stack.go:42 (0xcbd687)
/go/src/github.com/gruntwork-io/terragrunt/cli/cli_app.go:670 (0xcc5e4a)
/go/src/github.com/gruntwork-io/terragrunt/cli/cli_app.go:622 (0xcc5911)
/go/src/github.com/gruntwork-io/terragrunt/cli/cli_app.go:227 (0xcc2cc5)
/go/src/github.com/gruntwork-io/terragrunt/cli/cli_app.go:210 (0xcc29e5)
/go/src/github.com/gruntwork-io/terragrunt/vendor/github.com/urfave/cli/app.go:490 (0xc602e8)
/go/src/github.com/gruntwork-io/terragrunt/vendor/github.com/urfave/cli/app.go:264 (0xc5e55d)
/go/src/github.com/gruntwork-io/terragrunt/main.go:20 (0xccac84)
/usr/local/go/src/runtime/proc.go:201 (0x42c1b7)
/usr/local/go/src/runtime/asm_amd64.s:1333 (0x457fe1)

[terragrunt] 2019/07/10 20:25:33 Unable to determine underlying exit code, so Terragrunt will exit with error code 1

@yorinasub17 with regards to:

We just introduced the ability to disable the auto initialization of the backend in v0.19.7. Would this feature help with your use case?

This won't work for us. We don need to configure the remote backend. We just don't need Terragrunt to attempt to verify that such a bucket exists (and create it in case it doesn't). Or at least have a way to specify credentials for that via an explicit config field rather than just an environment variable. The best would be both: an option to disable it an option to pass credentials for that in case it's enabled.

Looking at https://github.com/gruntwork-io/terragrunt/blob/master/remote/remote_state_gcs.go#L387 I assume it was derived from https://godoc.org/cloud.google.com/go/storage#hdr-Creating_a_Client that explicitly tells:

The client will use your default application credentials.

I'm not sure I understand reasoning for assuming that default application credentials would work for access/creating GCS buckets that store such important data as state files.
It appears that it's possible to pass credentials explicitly via options and there are quite a few option about how credentials can be passed: https://godoc.org/google.golang.org/api/option#ClientOption
I don't feel I'm in position to suggest a certain approach to take but it looks like option.WithCredentialsFile can be used with the same value as the one supplied in credentials field for the gcs backend on its own. Or maybe you'd prefer to have a separate config option for this.

@robmorgan With S3, we read specific variables from the config about how to auth to the bucket: https://github.com/gruntwork-io/terragrunt/blob/master/remote/remote_state_s3.go#L112.
Could we do similar for GCS?

IMO that would be great! Any chances this can be implemented?

Hey guys on vacation at the moment. Will take a look in about 1-2 weeks.

Thanks for an update! No rush - just didn't want this to fall off the radar. I would've contributed this myself but I'm afraid there might be some design decisions involved that I don't have enough context for and it would be an order of magnitude more work this way.

I have a similar problem with v0.19.7. My GCS configuration looks like this:
remote_state {
  backend = "gcs"
  config = {
    prefix      = path_relative_to_include()
    credentials = "${get_terragrunt_dir()}/${find_in_parent_folders("credentials.json")}"
  }
}
terraform {
  extra_arguments "bucket" {
    commands = ["init"]
    arguments = [
      "-backend-config=${get_terragrunt_dir()}/${find_in_parent_folders("init.tfvars")}",
    ]
  }
  extra_arguments "creds" {
    commands = get_terraform_commands_that_need_vars()
    arguments = [
      "-var",
      "credentials=${get_terragrunt_dir()}/${find_in_parent_folders("credentials.json")}",
    ]
  }
}

inputs = {
  continent = "us"
  environment = "dev"
}

credentials.json is the service account key necessary to run terraform.
init.tfvars holds value for already created GCS bucketbucket = "my-state-bucket"

When i run terragrunt init i keep getting
[terragrunt] 2019/08/02 12:20:01 Missing required GCS remote state configuration project
[terragrunt] 2019/08/02 12:20:01 Unable to determine underlying exit code, so Terragrunt will exit with error code 1```

This code used to work perfectly in terragrunt 0.18.X with terraform 0.11.14.

Currently working on a new test case, hope to have a fix out later this week 👍

Sounds exciting! Thanks!

FYI - I have released https://github.com/gruntwork-io/terragrunt/releases/tag/v0.19.19 with @marko7460's fix.

@robmorgan thanks a lot!

When I am trying to use terragrunt for backend gcs, I am facing the error like below:
Error: Error parsing credentials 'terragrunt-test/auth.json': invalid character 'e' in literal true (expecting 'r')
terragrunt-test is my folder name and auth.json is my service account credentials file.
I am unable to understand why it is showing like.

Sounds like you have invalid JSON in the file? At any rate, please open a new issue to track this.

Sounds like you have invalid JSON in the file? At any rate, please open a new issue to track this.


Latest version throws an exception in smart contract

The following contract used to work in a previous build: https://github.com/mwherman2000/examples-csharp/blob/master/MainReturnsObject1/Contract1.cs#L12  ...but now throws an exception after I pulled the latest version from https://github.com/CityOfZion/neo-debugger-tools
Args:
operation: Hello
args: <nothing>
It used to work in the version that is still in my fork: https://github.com/mwherman2000/neo-debugger-tools
Cheers

The cause of the problem appears to be that args is set to &ltsnothing>.  It's good that parameter lists are working better now ...but if this is going to cause bad args to throw an exception, then Invoke Smart Contract dialog box should require you to enter the minimum required parameters.
p.s. Also add a text label to show the syntax for entering an array into the args parameter (please).

Done :)


Process with command "'hunspell' '-a' '-d' 'en_US'" has failed running with exit code 1(General error)

Upon trying the first example in the docs "Using the spellchecker directly" I get the following error
Process with command "'hunspell' '-a' '-d' 'en_US'" has failed running with exit code 1(General error)
$hunspell = Hunspell::create();

// en_US hunspell dictionary is available
$misspellings = $hunspell->check('mispell', ['en_US'], ['from_example']);
foreach ($misspellings as $misspelling) {
    $misspelling->getWord(); // 'mispell'
    $misspelling->getLineNumber(); // '1'
    $misspelling->getOffset(); // '0'
    $misspelling->getSuggestions(); // ['misspell', ...]
    $misspelling->getContext(); // ['from_example']
}

Upon checking installed dictionaries from Laravel I get the following error which is strange because from command line it works(see last code block for hunspell -D
Process with command "'hunspell' '-D'" has failed running with exit code 1(General error)
$hunspell = Hunspell::create();

$hunspell->getSupportedLanguages();

I tried first with Aspell and got the same error.
Do you have any pointers as to where the issue might be coming from?
Linux Mint 20
PHP 7.4
Laravel 6.20.16
I found that both Aspell and Hunspell were already installed on Linux mint.
$ aspell -v
@(#) International Ispell Version 3.1.20 (but really Aspell 0.60.8)
$ hunspell -v
@(#) International Ispell Version 3.2.06 (but really Hunspell 1.7.0)

$ hunspell -D
SEARCH PATH:
.::/usr/share/hunspell:/usr/share/myspell:/usr/share/myspell/dicts:/Library/Spelling:/home/USERNAME/.openoffice.org/3/user/wordbook:/home/USERNAME/.openoffice.org2/user/wordbook:/home/USERNAME/.openoffice.org2.0/user/wordbook:/home/USERNAME/Library/Spelling:/opt/openoffice.org/basis3.0/share/dict/ooo:/usr/lib/openoffice.org/basis3.0/share/dict/ooo:/opt/openoffice.org2.4/share/dict/ooo:/usr/lib/openoffice.org2.4/share/dict/ooo:/opt/openoffice.org2.3/share/dict/ooo:/usr/lib/openoffice.org2.3/share/dict/ooo:/opt/openoffice.org2.2/share/dict/ooo:/usr/lib/openoffice.org2.2/share/dict/ooo:/opt/openoffice.org2.1/share/dict/ooo:/usr/lib/openoffice.org2.1/share/dict/ooo:/opt/openoffice.org2.0/share/dict/ooo:/usr/lib/openoffice.org2.0/share/dict/ooo
AVAILABLE DICTIONARIES (path is not mandatory for -d option):
/usr/share/hunspell/en_CA
/usr/share/hunspell/en_ZA
/usr/share/hunspell/es_US
/usr/share/hunspell/es_SV
/usr/share/hunspell/en_AU
/usr/share/hunspell/es_VE
/usr/share/hunspell/es_NI
/usr/share/hunspell/pt_PT
/usr/share/hunspell/pt_BR
/usr/share/hunspell/es_BO
/usr/share/hunspell/es_PA
/usr/share/hunspell/es_PY
/usr/share/hunspell/es_HN
/usr/share/hunspell/en_GB
/usr/share/hunspell/es_CU
/usr/share/hunspell/de_DE
/usr/share/hunspell/de_CH_frami
/usr/share/hunspell/es_CO
/usr/share/hunspell/fr_CH
/usr/share/hunspell/fr
/usr/share/hunspell/de_DE_frami
/usr/share/hunspell/de_AT_frami
/usr/share/hunspell/es_PR
/usr/share/hunspell/es_AR
/usr/share/hunspell/de_AT
/usr/share/hunspell/es_UY
/usr/share/hunspell/en_US
/usr/share/hunspell/fr_FR
/usr/share/hunspell/fr_CA
/usr/share/hunspell/it_CH
/usr/share/hunspell/de_CH
/usr/share/hunspell/ru_RU
/usr/share/hunspell/es_ES
/usr/share/hunspell/es_DO
/usr/share/hunspell/fr_LU
/usr/share/hunspell/es_GT
/usr/share/hunspell/es_CL
/usr/share/hunspell/es_MX
/usr/share/hunspell/fr_BE
/usr/share/hunspell/fr_MC
/usr/share/hunspell/es_CR
/usr/share/hunspell/it_IT
/usr/share/hunspell/es_EC
/usr/share/hunspell/es_PE
/usr/share/myspell/dicts/fr_CH
/usr/share/myspell/dicts/hyph_ru_RU
/usr/share/myspell/dicts/fr_FR
/usr/share/myspell/dicts/fr_CA
/usr/share/myspell/dicts/fr_LU
/usr/share/myspell/dicts/fr_BE
/usr/share/myspell/dicts/fr_MC

Hey @warmwhisky,
Sorry for being late on this issue, didn't receive any notification.
This is indeed weird, tests are passing on the CI with regular Debian docker image.
Could you try to execute echo 'mispell' | hunspell -i utf-8 -a -d en_US on the command line and give me the output.
Hunspell class is more or less running this command when spellchecking so if it works on the command line then we'll have to focus our investigation on the lib side.
Btw if the lib has been helpful to you don't hesitate to star the project, thanks !

Closing untill new infos

Hello, how are you, I wanted to know if they could solve it, the same thing happens to me and I can't find the solution. Thank you!

Could you try to execute echo 'mispell' | hunspell -i utf-8 -a -d en_US on the command line and give me the output.
Hunspell class is more or less running this command when spellchecking so if it works on the command line then we'll have to focus our investigation on the lib side.
Also could you give me the output of composer info -i.

Hi, I am having the same problem. This is the output of:
echo 'mispell' | hunspell -i utf-8 -a -d en_US
@(#) International Ispell Version 3.2.06 (but really Hunspell 1.7.1)
& mispell 4 0: misspell, mi spell, mi-spell, spell

Hey @alketii, seems like there's an issue on php call side then.
If you can debug what's the error output of the console command ran while spellchecking and post it here that would be helpful.
In the meantime, I'll try to improve the exception by gathering more information about the error to ease debugging in a next version. I'll keep you updated.

Could you help me with the command, I am not sure which one to run.

I was able to pinpoint the problem.
I am using Mac and it has zsh shell. I install hunspell with Homebrew and the PATH of hunspell was set only at zsh, not to sh which PHP uses.

@alketii wow, thanks for your investigation.
Now I'm wondering how to solve this 🤔
Did you find a solution to use the current shell instead of the sh one?

I looked into changing the shell but with no luck.
I ended up changing line 93 of Spellchecker/Hunspell.php to the full path of hunspell
 return new self(new CommandLine($binaryPathAsString ?? '/opt/homebrew/bin/hunspell'));
Since the production uses Linux, I didn't put much thought.