241 multiple nav stack

Fixing issue of duplicate screens being added to the navigation stack on rapid event taps
issue here: https://github.com/redbadger/pride-london-app/issues/241
Was solved by upgrading react-navigation package to v2.
This required minimal code changes, only deprecation of previous navigation creator functions which have been replaced by new mostly identical functions - save for the tabNavigator creator.
Rendering of the TabBar was broken upon upgrade, fixing this uncovered that the Animated components for the icons and labels weren't being used so have swapped them out for their basic counterparts.

[ ] Tested on multiple devices / OS versions (Test on the physical device(s) you have access to, otherwise use BrowserStack):

[ ] Galaxy S8 (Android 7.0/8.0)
[ ] Galaxy S7 (Android 6.0)
[ ] iPhone X (iOS 11.x)
[ ] iPhone 8 (11.x)
[ ] iPhone 7 (iOS 10.x)

Optional:

[ ] Google Pixel 2
[ ] Galaxy S8 Plus
[ ] Galaxy S7 Edge
[ ] Galaxy S6
[ ] iPhone 7+
[ ] iPhone 6

With respect to the headerMode:"none" problem, I believe static properties on screen components no longer works. I think there is a way to declare this within the navigation setup though.

I would suggest we get test to double check this too before it goes out, just in case we missed something.

Okay, headerMode is obviously working just fine 🙈. What I meant is:
static navigationOptions = {
  tabBarVisible: false
};

the tabBarVisible issue has now been addressed, but I'd love it if anyone has any advice if there's a cleaner way to do it

I think we only want the tab bar to be visible on the initial route of a tab. On all sub routes it should be hidden. So maybe something like this would make it a bit simpler:
import type {
  NavigationScreenConfigProps,
  NavigationTabScreenOptions
} from "react-navigation";

const hideTabBarOnSubRoutes = (
  initialRouteName: string,
  navigationOptions: NavigationTabScreenOptions
) => ({ navigation }: NavigationScreenConfigProps) => {
  const { routeName } = navigation.state.routes[navigation.state.index];
  return {
    ...navigationOptions,
    tabBarVisible: routeName === initialRouteName
  };
};

const TabNav = createBottomTabNavigator(
  {
    [HOME]: {
      screen: HomeStack,
      navigationOptions: hideTabBarOnSubRoutes(HOME, {
        tabBarIcon: tabIcon(iconHomeDefault, iconHomeActive),
        tabBarLabel: text.tabHome
      })
    }
  }
);

It would make flow happy, too, as far as I can see.

I love this, thank you! I went through all the screens to check for the
static nav option of tabBarVisible set to false but I guess my
in-familiarity with the app tripped me up in realising that it was only
meant for the initial routes :)
On 14 May 2018 at 21:03, Jan Kühle<EMAIL_ADDRESS>wrote:

I think we only want the tab bar to be visible on the initial route of a
tab. On all sub routes it should be hidden. So maybe something like this
would make it a bit simpler:
import type {
NavigationScreenConfigProps,
NavigationTabScreenOptions
} from "react-navigation";
const hideTabBarOnSubRoutes = (
initialRouteName: string,
navigationOptions: NavigationTabScreenOptions
) => ({ navigation }: NavigationScreenConfigProps) => {
const { routeName } = navigation.state.routes[navigation.state.index];
return {
...navigationOptions,
tabBarVisible: routeName === initialRouteName
};
};
const TabNav = createBottomTabNavigator(
{
[HOME]: {
screen: HomeStack,
navigationOptions: hideTabBarOnSubRoutes(HOME, {
tabBarIcon: tabIcon(iconHomeDefault, iconHomeActive),
tabBarLabel: text.tabHome
})
}
}
);
It would make flow happy, too, as far as I can see.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/redbadger/pride-london-app/pull/266#issuecomment-388944300,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AThKCNn-YM786f2y6MRdyLaY5ky1NbGKks5tyeMegaJpZM4T4n5b
.

No worries. I believe we changed this mid-way, so now the tab bar is hidden for all sub routes. But you might want to clearify this with someone from the design/UX team 🙂.


markers of cut in imglab

hi Davis,
do you think it is possible to have in imglab "markers of cut" that would follow the mouse as in this image ?

this would greatly facilitate the selection of objects.
regards, lacsaP.

Additionally, being able to clear, move (drag), and resize the placement of a selection box, and showing  (x, y, width, height) of the current box while it's being drawn or resized.

You can already remove or resize boxes.

Just added this to imglab :)

thanks Davis !

No problem


Set custom headers for checking is_resumable

Feature request

Current Behavior
At the moment is_resumable uses a HEAD request with no headers so requests requiring basic auth aren't resumable.

Possible Solution

I think the HEAD request should be sent with the same headers as the main GET request. There could potentially be reasons why you would want to send it with separate headers for each but I cannot think of any right now.

Thanks for reporting the issue 👍
It should not be too difficult to fix, probably as simple as setting the default headers when we create the client or something like that. I'll need to dig a little, but would you happen to have an example I could use to reproduce the problem by any chance?

This solved my problem, thanks!


⚠ Bofrost.lu has degraded performance

In 7a103cd, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 2419 ms

Resolved: Bofrost.lu performance has improved in ca45aac after 6 minutes.


[QUERY] Is there guidance on checkpointing on PartitionClosingAsync when using the EventProcessorClient?

Query/Question
Our scenario is that we checkpoint given an interval (X number of seconds) and we want to safely checkpoint an event when the partition is closing, due to a shutdown or perhaps when ownership of the partition changes.
What is the recommended approach to creating a checkpoint when a partition is closing? Should we be creating a concurrent dictionary to checkpoint the last event for the particular partition before it is closed, similar to
the example in https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/eventhub/Azure.Messaging.EventHubs.Processor/samples/Sample04_ProcessingEvents.md#checkpointing-while-processing? Instead of a ConcurrentDictionary<string, int>, a ConcurrentDictionary<string, ProcessEventArgs> would be used to checkpoint the last event processed but not checkpointed?
Would the OnPartitionProcessingStoppedAsync handler for the current processor instance be executed before a new processor instance calls its OnInitializingPartitionAsync handler?
Environment:

Name and version of the Library package used: Azure.Messaging.EventHubs.Processor v5.6.1
Hosting platform or OS and .NET runtime version (dotnet --info output for .NET Core projects): .NET 5
IDE and version : VS 16.11.2

Hi @stambunan.   Thank you for reaching out and we regret that you're experiencing difficulties.
With respect to the scenario where the processor is shutting down and you'd like to record a final checkpoint, the general approach that you're describing is what we would recommend.  You'd need to preserve the last set of ProcessEventArgs  that hasn't been checkpointed so that you can access them to create the final checkpoint in your PartitionProcessingStopped handler.    The proposed concurrent dictionary is a reasonable way to do so.
For partitions changing ownership, there is no reliable way to write a final checkpoint before ownership changes.   In order to prioritize throughput and reduce complexity in the hosting environment, processors do not communicate peer-to-peer nor is there a central orchestrator that directs an ordered hand-off.  Instead, ownership coordination is performed in a loose manner using Storage as the intermediary.
When processors are added/removed from the group or a processor is no longer able to communicate with Storage, ownership of partitions will change.  During that time, the new owner will begin processing once Storage accepts their request to update the ownership record.  The old owner may still be processing the last batch of events read and won't become aware that their ownership was lost until the next time they attempt to read from the partition or the next load balancing cycle occurs.
It would be possible to manually force a checkpoint before you scale processors by tracking the ProcessEventArgs in the manner that you proposed earlier and having the host application respond to some sort of notification that scaling is about to occur.   In the extreme, that could be used to stop all processing to ensure final checkpoint stability before scaling and then restarting after scaling.
For a more robust approach, you could write an orchestrator that assigns a specific set of partitions to a processor, notifies it when it is losing ownership, and waits for the final checkpoint, and then hands the partition to another instance.  That, of course, comes with additional complexity, performance costs to overall throughput, and the need to build resilience into the orchestrator or accept a single point of failure.
I'm going to mark this as addressed, but please feel free to use the "/unresolve" command if you'd like to continue the discussion.


Create me.is-cool.me.json

Requirements

[x] You have completed your website.
[x] The website is reachable.
[x] The CNAME record doesn't contain https:// or /.
[x] There is sufficient information at the owner field.

Description

Link to Website

I have read the CLA Document and I hereby sign the CLA

recheck


contrib: Add script to bump stable docker image tags

@aanm I didn't want to click all the buttons to make that happen :joy: Did we ever figure out a way to automate all the dockerhub UI interactions?

@aanm I didn't want to click all the buttons to make that happen  Did we ever figure out a way to automate all the dockerhub UI interactions?

Yes, once GH actions are done for cilium/cilium we should be good for >=1.9

@aanm is that tracked somewhere specifically and is it planning to address both the v1.X.Y release image building / triggering as well as updating the stable tags?
If the stable tag update will be handled by some other logic for v1.9 then I'll drop this PR.

@aanm is that tracked somewhere specifically and is it planning to address both the v1.X.Y release image building / triggering as well as updating the stable tags?
If the stable tag update will be handled by some other logic for v1.9 then I'll drop this PR.

We'll have to double check this once we have it running

@aanm oh, I guess there was a disconnect here. I marked this as draft under the assumption it's not necessary at this point. But it also has priority/release-blocker. Maybe I'll revert from draft again and we can evaluate whether to accept or just close it out.

@joestringer I might have marked this PR as release-blocker by accident

@aanm given that we didn't address this for 1.9, would it be worthwhile for me to re-spin this PR to merge? There's now eight different images to configure the build targets on dockerhub each time.

@aanm given that we didn't address this for 1.9, would it be worthwhile for me to re-spin this PR to merge? There's now eight different images to configure the build targets on dockerhub each time we do a 1.9.x release.

@joestringer it depends, as soon we have the GH actions builds done, we don't need to configure anything on docker hub anymore.

@aanm that answer has not changed for the last six weeks. Do we have concrete expectations that those steps will occur in the short term? If not, I suggest we merge this as-is and revert whenever that system is fully set up.

@aanm that answer has not changed for the last six weeks. Do we have concrete expectations that those steps will occur in the short term? If not, I suggest we merge this as-is and revert whenever that system is fully set up.

@joestringer I thought you had to make further changes to this PR if that's not the case I'm fine to merge it as is

:+1: Just needed a rebase, already done.


audio sampling error

hi, i tried to run supersid.py on raspberry pi 3 but i keep getting this error. i  have install pyalsaaudio but this message would not clear. pls help
From Sampler object instance:
Could not open capture device. Please cError alsaaudio
global name 'alsaaudio_soundcard' is not defined
To debugg: remove the try/except clause to get detail on what exception is triggered.
Traceback (most recent call last):
File "supersid.py", line 226, in
sid = SuperSID(config_file=args.config_file, read_file=args.filename)
File "supersid.py", line 100, in init
self.close()
File "supersid.py", line 188, in close
self.sampler.close()
File "/home/pi/Desktop/supersid-master/supersid/sampler.py", line 221, in close
self.capture_device.close()
AttributeError: Sampler instance has no attribute 'capture_device'

What soundcard are you using and is it set to be the default one? I've seen similar messages when the built in sound-out-only (HDMI or headphone jack) was the default card still.


Fix environment variables GUI for new apps

Description

This pull request addresses a bug in the Stratos GUI that caused issues with displaying and managing environment variables for new applications in the GUI.
The fix ensures that the environment variables object is not NULL and provides an empty object if necessary.
Motivation and Context

When a new app was created, the environment variables were not shown correctly.
This was caused by a NULL entry.
The entry prevented the GUI from displaying the environment variables correctly because it had nothing to iterate over.
It also prevented the setting of new variables and prevented variables that were set manually from being shown.
This was solved by inserting an empty object if the variable is currently set to NULL.
How Has This Been Tested?
This fix has been running on the STACKIT Stratos for two years.
It was manually tested by creating a new application and testing that the env variables were shown correctly and were editable in the GUI.
Types of changes

[X] Bug fix (non-breaking change which fixes an issue)
[ ] Docs update
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[X] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[X] I have followed the guidelines in CONTRIBUTING.md, including the required formatting of the commit message

Straightforward change, great PR!


Unconcious adds stacks to Prone

Foundry version 10.291
Pathfinder version 4.6.8
Bug present with all other modules disabled
Replication: from the right click menu on a placed token, click the unconscious effect to apply it to that token, then right click the unconscious effect to remove it from that token, then click&rightclick a few more times before finally making the character stay conscious. Next, go to remove prone from the character on the effects tab, or by right clicking the effect in the active effects popup for that token. Prone will only disappear from the character's active effects list once it has been removed the same number of times as the conscious/unconscious cycle was repeated.
This situation can be made worse if prone is incremented or decremented too quickly, which can put the character in a state where the client must reload the page before being able to correctly continue removing the excess prone states.
Recommended solution:

for every condition, the "delete" trash can icon in the character sheet effects tab should set the condition number directly to zero, rather than only decrementing by one for effects which are expected to be binary. For example, if a player is "enfeebled 30", they can click the trash can icon and it correctly removes all stacks. For prone, this is not the case, and it only decrements one stack per click.

for unconscious specifically, add a validation condition to not increment prone if prone is already at 1

Holy cow that was fast!
Thank you


Add minimum OS version for all flags

Backfill minimum OS versions for all pnputil flags. Flags introduced in Win 11 21H1 or later have minimum versions documented, but pre-Win 11 flags had no specified minimum version.

Thanks Emily this looks great!


Feature: measurement progress printer

This contains a small class to monitor the progress of a measurement by adding a subscriber, like so:
from qcodes.utils.measurement_subscribers import TextProgress

meas = qcodes.Measurement()

meas.register_custom_parameter("x")
meas.register_custom_parameter("y", setpoints=("y",))

xs = np.linspace(-1, 1, 2000)

meas.add_subscriber(TextProgress(total_measurements=xs.size), state=None)

with meas.run() as datasaver:
    for x in xs:
        meas.add_result(("x", x), ("y", np.random.randn()))
        time.sleep(0.01)

This prints something like
105 / 2000 (5.2%) - elapsed: 0:00:01 - ETA: 0:00:19 (Fri Oct 11 12:34:56)

It's nothing fancy, but I think something like this should be built-in.
Some things to consider:

Is it a good idea to have a full module for this? Or should it just go to helpers?
This should be mentioned in some of the example notebooks. I think it could be added to the Dataset context manager notebook as a third example, to the Example measurements with real instruments, and maybe to the 15 Minutes to Qcodes notebook. Do you have other suggestions?
The start and end times are a bit fudgy, since the subscriber function has no real way of knowing if it is being called on the first or last insertion (maybe the subscriber API could be extended)
With an ArrayParameter/MultiParameter, the array sizes need to be taken into account in total_measurements, this should be probably mentioned somewhere

@astafan8

Indeed this is a very useful functionality. But just from your example, I feel a similar result can be achieved by using tqdm. Am I missing something important here?

I tried tqdm at some point. My first issue was that it didn't handle nested loops properly, although the tqdm_notebook widget which I hadn't seen earlier seems to work well with that. The second problem I had was that for long measurements, I'd like to have an estimate of the finish time as a date, so I don't have to do so much mental arithmetic to figure out what is the current time plus 14 hours. This doesn't seem to be easy to do with the tqdm formatting options, at least at a quick glance.

Thank you for the insightful comments! You are right, I should look into tqdm more carefully instead of reinventing the wheel. I suppose that the takeaway here is that tqdm should be mentioned in the documentation somewhere. I will close this PR now, and maybe I'll open a new one for updating the docs.

I agree with the "Dataset context manager notebook as a third example"

Do you suggest that tqdm should be adapted to work with the subscriber API? I tried this also, but had problems with the output formatting, although that was without the notebook integration. Or should the example show using tqdm just like
with meas.run() as datasaver:
    for x in tqdm_notebook(xs):
        datsaver.add_result( ... )

in which case it's a bit odd that it would be part of a tutorial on using subscribers.

I will close this PR now, and maybe I'll open a new one for updating the docs.

ok!

Do you suggest that tqdm should be adapted to work with the subscriber API?

yes, in case you still intend to implement smth like ProgressBar subscriber that uses tqdm behind the scenes. If not, then there's no need to mention tqdm in the subscriuber notebook, because as you point out here:
with meas.run() as datasaver:
    for x in tqdm_notebook(xs):
        datsaver.add_result( ... )

tqdm can be used just "as is". However, it is probably "nice to hint users towards using tqdm" in the "Dataset context manager notebook" in the way such as:

If you want to see the progress of your measurement, you can use this very nice tqdm package. Btw, qcodes uses it internally already so it is already installed with qcodes. Hence, just read about it and tailor it to your specific needs, for example:
with meas.run() as datasaver:
    for x in tqdm_notebook(xs):
        datsaver.add_result((.., x), ... )

Just for reference: I looked into tqdm a bit more, to get the ETA to display like I wanted. Apparently, with the Jupyter integration, this doesn't work properly right now (following the instructions here lead me to this issue). I got it working by hackishly parsing the progress bar string, as suggested in the comments here. This negates the "low overhead" of tqdm, but maybe that's not such a big issue when doing measurements that anyway take 10-1000 milliseconds (it could probably also be alleviated by using the Qcodes subscriber API).
from datetime import datetime, timedelta
from tqdm.notebook import tqdm

xs = np.linspace(0, 1, 1001)

def parse_progressbar_eta(bar) -> int:
    eta = str(pbar).split("<")[-1].split(",")[0].split(":")[::-1]
    eta = sum(60**i * int(e) for i, e in enumerate(eta))
    return eta

pbar = tqdm(total=xs.size)

for x in xs:

    time.sleep(0.01)

    pbar.update()

    eta = parse_progressbar_eta(pbar)

    finish_time = datetime.strftime(datetime.now() + timedelta(seconds=eta),
                                    format="%a %b %d %H:%M:%S"
                                   )
    pbar.set_postfix_str(finish_time, refresh=False)

pbar.close()


RFC: Consolidate Eigen feature flags - Retire Echo

This RFC proposes the consolidation of feature flags within Eigen into a single platform: Unleash.
Reasoning
Misalignment of Feature Flags Across Surfaces
Across various Artsy surfaces, feature flags are managed using Unleash. Engineers are accustomed to adding flags there, using supporting tools (https://tools.artsy.net/feature-flags) and directly through https://unleash.artsy.net. However, Eigen continues to utilize Echo for feature toggles, leading to inconsistency and potential operational challenges.
Complexity in Running Experiments
Conducting A/B tests in Eigen poses challenges, necessitating the use of two flags: - An Echo flag to toggle when development is complete - An Unleash flag to define the split This dual-flag approach complicates experimentation and requires additional coordination.
Limitations in Rollout Strategies
Echo flags lack advanced rollout capabilities present in Unleash. Gradual rollouts and user ID-based rollouts, critical for controlled feature releases, are not easily achievable. Migrating to Unleash would provide these capabilities out of the box, enhancing our deployment strategies.
Management of Legacy Flags
Unlike our experiments infrastructure, Eigen lacks a fallback mechanism for missing flags from Echo. Consequently, outdated flags are retained in echo.json to prevent unintended feature toggling for legacy clients and reusing the same key. This approach is "unsustainable" and could benefit from a safer approach around archiving old flags.
Exceptions
No exceptions are warranted. Echo's retirement is recommended.
Additional Context
Discussions on this matter have occurred previously, notably here and here.
Resolution of this RFC

Agreement on retiring Echo and transitioning all feature flag management to Unleash.
Formulation of a technical plan, documented and added to Sapphire's board for further action.
Implementation of the proposed technical plan, following up on the suggested approach.

1000% in favor of that, thanks for taking the initiative!
Small question, are we keeping the same concept of readyForRelease when moving to Unleash or are we exploring a different approach, maybe by versions? Perhaps this question is more for the tech plan rather than here.

I am also in favor of that 100% there are some things though that we need to take into account before we start doing that:

What happens with the already existing echo feature flags that we do have out there?

Since mobile releases are a bit different and older versions stay active for some users for a longer period what happens if somebody accidentally archive a feature flag that was created in unleash?

We need an explicit naming conventions for the feature flags and the ab test flags.

Echo also has some extra capabilities like killswitch for older versions should we keep it around just for this or should we explore other options?

I don't work closely with Eigen, and the technical implications are unclear to me. But if this is feasible, it would be great!
In the past, the former NX team took 1 month to realize a feature wasn't released due to our lack of understanding of feature flags handling in Eigen (ref). There are, of course, several other steps that we missed and should have prevented something like that. We all learned from it as a team. Still, if a unified process for feature flags is possible, it can make a huge difference eng-wide to avoid issues like that in the future.

What happens with the already existing echo feature flags that we do have out there?

Since Echo deploys to a S3 bucket, we could potentially leave the static JSON file there indefinitely for legacy clients.

mostly in favor of consolidating same questions as @gkartalis here:
Echo also has some extra capabilities like killswitch for older versions should we keep it around just for this or should we explore other options?  We could just deprecate feature flags from Echo and keep the rest of the stuff.
also I think we need some form of readyForRelease or a way of not shipping in progress work for this to replace Echo feature flags. Maybe warrants some thought but with that existing I think there is still always a chance someone forgets to release something no matter if the flag comes from echo or unleash.

@araujobarret

Small question, are we keeping the same concept of readyForRelease when moving to Unleash or are we exploring a different approach, maybe by versions? Perhaps this question is more for the tech plan rather than here.

Imo, we should keep the same logic we have currently, the reason behind that is that we kind of get out of the box release all upcoming versions with it without much effort

@gkartalis

What happens with the already existing echo feature flags that we do have out there?

In order not to break any current behavior and to make this change seamless, I would suggest migrating the existing flags to unleash.

Since mobile releases are a bit different and older versions stay active for some users for a longer period what happens if somebody accidentally archive a feature flag that was created in unleash?

If the flag is archived, it's no longer going to be available to client SDKs. This triggers Eigen's logic of returning the fallback variant. This is IMO fine, it's actually better than now since we don't handle that. Ideally, we should not archive flags unless we see they're not getting any traffic.

We need an explicit naming conventions for the feature flags and the ab test flags.

We actually have spoke about this before here https://github.com/artsy/README/issues/507. Adding a feature flag from https://tools.artsy.net makes that quite easy, it's only not trivial when adding through https://unleash.artsy.net.
Our current feature flags use AREnableXFeature pattern. This came from when we were only iOS and it was the preferred pattern, I am fine with moving over that.

Echo also has some extra capabilities like killswitch for older versions should we keep it around just for this or should we explore other options?

I believe it makes sense to move those to unleash as well, but initially, I would do @joeyAghion 's suggestion and keep them in json in s3. So far, in the past 3 years. I barely recall one time that we changed them, so I would be fine with migrating them only at a later stage

In the past, the former NX team took 1 month to realize a feature wasn't released due to our lack of understanding of feature flags handling in Eigen (ref). There are, of course, several other steps that we missed and should have prevented something like that. We all learned from it as a team. Still, if a unified process for feature flags is possible, it can make a huge difference eng-wide to avoid issues like that in the future.

Same thing happened to us in Onyx and it was the initial thing that motivate me to look into this further, I notes some issues in Notion and shared them with the team at #ab-testing over slack. We came up with a checkbox to make sure that the best practices are clear. You can check it here https://github.com/artsy/eigen/blob/main/docs/a_b_testing_best_practices.md. I think a similar doc would be great for other surfaces as well

we do change the killswitch semi-regularly: https://www.notion.so/artsy/0b3cda79f9884a77a4950798410dc753?v=6f87f04d4a644bc787ed861637238efc it is seldom but also a pretty critical functionality to be sure we can retire legacy features. some of this stuff is not really equivalent to a feature flag so not sure it belongs in unleash: https://github.com/artsy/echo/blob/5da4cf7efea38fecede02efe40bbda83a0339d32/Echo.json5#L178

Also, things like kill-switches and the like are pretty much unnecessary now thanks to CodePush.

Regarding A/B testing and enforced naming, because we have the ability to manage Feature Flags in our tools admin, this is trivial. We use the drop down to append the team name now:

And if we needed to update this with another input that controls the naming via the experiment checkbox, we could also do that trivially:

Also, things like kill-switches and the like are pretty much unnecessary now thanks to CodePush.
disagree on this one, codepush does not eliminate old versions existing in the wild, and codepush updates can only target compatible versions.

Been dreaming about this one for a long time! Thank you. The multiple FF layers are so confusing 👍
After wiring in Unleash into Folio the other day it also got me wondering why this layer is so complex in Eigen, and if it needs to be. As far as flag environments go, we've got the beginnings of convos in Folio, production flag is unchecked till its ready and things are hidden from users. When its ready, check the prod flag in our tools FF admin. If something goes wrong during the eventual release, we uncheck prod in tools and folks are none the wiser 🤷 And when the feature is stable, we remove the flag. Everything remains simple and its no big deal. There's a process, and guardrails.
If we (needed) another layer like ready for release (I don't think we do!) maybe we could spin up another env in Unleash. Right now we have staging / prod, and it (seems) like we could add one more. (I hope we don't do this though.)

I am confused about how this works with a flag on the server side. The scenario I am thinking about is a long running feature in dev behind a flag. While that flag is in various stages of dev multiple versions of the app get released, say versions 1, 2, 3. Since the flag is disabled great, no one sees it but the actual code in the app is incomplete until version 3. We release version 3 enable the feature flag and then users still on 1 and 2 see broken code. How do we get around this without a check in the client or a version check on the server?

We lean into app store releases and auto-updates, and if we need extra security around this we can wire up an intermediate layer.

killswitch is something you ideally should need seldomly but are very happy to have when we do need it. basically every app I have worked on ended up building some functionality like this over time otherwise you get stuck maintaining old apis and functionality indefinitely. For example over the last few years we have used it to force upgrade users on old versions that were using old apis with security concerns. This targeted force upgrading is just not possible with codepush, it serves a different purpose in my mind. I guess my question would be why get rid of it if we already have it, just leave it in echo as peace of mind for when we need it. Why not just restrict this RFC to just deprecating feature flags from echo since that seems to be the main pain point?
separately, shipping in progress/broken code in my opinion is not acceptable and something we need to actively have a plan to prevent. It is just a reality of mobile dev that multiple versions of the app are going to exist in the wild, codepush or not.  I think this is a very solvable problem with feature flags in unleash, just think it needs to be solved.

Re. kill switches, I wonder if we (in the long term) can rely on Unleash for those too? Basically we'd just need a feature defined that specifies a minimum compatible app version. There seems to be some built-in support for this, for strategy constraints to govern whether a feature is enabled via semantic version comparisons.

Why not just restrict this RFC to just deprecating feature flags from echo since that seems to be the main pain point

To be honest, my primary objective with this RFC is to streamline the management of feature flags by consolidating them within Unleash rather than Echo. While I understand the importance of discussing other values within Echo, I believe it's best to address that separately. This isn't to dismiss their significance, as they do intersect with our current focus, but rather to ensure clarity and focus on resolving the confusion surrounding feature toggles and experiments. I will follow-up with these broader discussions separately at the practice

That's what I understood from this RFC, all the details would be discussed/agreed upon at the tech plan level considering the idea here and what we want to achieve is feasible.

Alright but I am just reacting to: No exceptions are warranted. Echo's retirement is recommended. which makes it sound like we are killing echo so was a little concerned. Can we update this to reflect that we are only talking about feature flags?

@brainbicycle Updated the description as well as the RFC title. Thank you.

Resolution
I Spoke further about this with folks separately and we are good to go 🚀 . This work is now part of Sapphire OKRs for the next quarter. I will lead this effort in Eigen along with @mc-jones
Level of Support
2: Positive feedback.
Next Steps
Start with the tech plan
Exceptions
Only feature flags will be migrated from Echo, everything else will remain as it is.


[wip][rest-server] error message about token expiration.

Coverage increased (+0.009%) to 48.425% when pulling 4b7dcb08c09979d0fcac59181a3188369bbe3fce on yuye/token-expire-error-rs into 9ca28addda0b8ac08bb85f477b4095019a45e1fb on master.


Run tests in randomized order

The google test framework has very handy option to run tests in a randomized order (with optional number of repetitions). This can reveal problems with hidden tests and/or test fixtures dependencies. I cannot find a similar feature in Ceedling, so I guess it is a feature request then :)
Here's a reference to google test docs (search for "Shuffling the Tests"): http://google.github.io/googletest/advanced.html

Is there any interest to implement such a feature?

@radoslav06 I am familiar with that feature of Google Test. Seems worthwhile, yes. We'll put it in the backlog for post-1.0.0 work.


fix: set correct user type when importing from emby

Description
When importing users from Emby now it sets and displays the correct user type.
Screenshot (if UI-related)

To-Dos

[x] Successful build pnpm build
[ ] Translation keys pnpm i18n:extract
[ ] Database migration (if required)

Issues Fixed or Closed

Fixes #948

:tada: This PR is included in version 2.0.0 :tada:
The release is available on:

v2.0.0
GitHub release

Your semantic-release bot :package::rocket:


Making scripts executables

Adding +x permission to scripts

Hi @soleti,
You have proposed changes to files in these packages:

Scripts

which require these tests: build.
@Mu2e/fnalbuild-users, @Mu2e/write have access to CI actions on main.
:hourglass: The following tests have been triggered for 14ea6156f6a6f09a505c2d9b1d037055dca61062: build  (Build queue is empty)
About FNALbuild. Code review on Mu2e/Offline.

:sunny: The build tests passed at 14ea6156f6a6f09a505c2d9b1d037055dca61062.

Test
Result
Details

test with
:white_check_mark:
Command did not list any other PRs to include

merge
:white_check_mark:
Merged 14ea6156f6a6f09a505c2d9b1d037055dca61062 at cb177e56cfedd511d9871ce431c39ec201a17914

build (prof)
:white_check_mark:
Log file. Build time: 12 min 35 sec

ceSimReco
:white_check_mark:
Log file.

g4test_03MT
:white_check_mark:
Log file.

transportOnly
:white_check_mark:
Log file.

POT
:white_check_mark:
Log file.

g4study
:white_check_mark:
Log file.

cosmicSimReco
:white_check_mark:
Log file.

cosmicOffSpill
:white_check_mark:
Log file.

ceSteps
:white_check_mark:
Log file.

ceDigi
:white_check_mark:
Log file.

muDauSteps
:white_check_mark:
Log file.

ceMix
:white_check_mark:
Log file.

rootOverlaps
:white_check_mark:
Log file.

g4surfaceCheck
:white_check_mark:
Log file.

FIXME, TODO
:white_check_mark:
TODO (0) FIXME (0) in 0 files

clang-tidy
:white_check_mark:
0 errors 0 warnings

N.B. These results were obtained from a build of this Pull Request at 14ea6156f6a6f09a505c2d9b1d037055dca61062 after being merged into the base branch at cb177e56cfedd511d9871ce431c39ec201a17914.
For more information, please check the job page here.
Build artifacts are deleted after 5 days. If this is not desired, select Keep this build forever on the job page.


fix(userconfig): plan doesn't show zero values for new resources

Zero values are not displayed on plan because d.HasChange(k) returns true for new resources.
They just don't have changes.

tests


Make Path to project relative to chunk file

Possible fix for:
https://github.com/dita-ot/dita-ot/issues/2298
The path to project PI inside the chunk file needs to be computed relative to the chunk file and not to the original file location.

Closing as invalid. Leads to side effects.


Persist a preferences object in local storage and populate redux object from it on application mount

No redux, turn into usePreferences hook

completed in v2


format_skip_control_chars

Fixes #262

Thanks, the change itself looks good. It would be great to add a simple unit tests and add this flag to manual (docs/manual.adoc) - you can find any other format flag in tests/docs for guidance. No need to rebuild HTML documentation, the setup process for that is nontrivial if you’re on Windows...

Done. By the way debugging unittest was tricky since it only printed expected string, but not the actual result.
And about 18 unit tests were failing on Linux gcc 8.2.0... I'll take a look while be near my linux machine, maybe the cause was I was running them from wrong directory.

make test should run them from the correct folder

Merged, thanks!


typo: Double word "to"

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

biztalk/core/business-rule-engine-security-recommendations.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Facebook login is not working on real Android devices

On real IOS devices and Android emulator, it's ok. But on real Android devices, it's not working.
https://youtu.be/vi5AFV0mFSY
Thanks in advance!

I am also facing same with
FBLoginManager.LoginBehaviors.Native but
FBLoginManager.LoginBehaviors.WebView works fine

I am also facing same with
FBLoginManager.LoginBehaviors.Native but
FBLoginManager.LoginBehaviors.WebView works fine

were you able to login successfully? I am getting App is not setup. App is still in developement error while doing Login.


can't find the ssid on my network NMEA Bridge

The ssid says ESP-XXXXX and the password is unknown. I used a new ESP8266 chip, but everything remains as it was at the beginning. Changing the network name and password is not possible. Use Arduino IDE2.1 It's a shame I would have liked to try this thing out. greeting

Did it compile and flash without errors; what was the logging output?

C:\Arduino Ockam ersatz\nmea-bridge-main\nmea_bridge\nmea_bridge.ino: In function 'void handle_udp_event()':
C:\Arduino Ockam ersatz\nmea-bridge-main\nmea_bridge\nmea_bridge.ino:513:54: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
  513 |             handle_incoming_sentence(buffer, length, "udp");
      |                                                      ^~~~~
C:\Arduino Ockam ersatz\nmea-bridge-main\nmea_bridge\nmea_bridge.ino: In function 'void handle_websocket_event(uint8_t, WStype_t, uint8_t*, size_t)':
C:\Arduino Ockam ersatz\nmea-bridge-main\nmea_bridge\nmea_bridge.ino:533:63: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
  533 |             handle_incoming_sentence((char )payload, length, "ws");
      |                                                               ^~~~
C:\Arduino Ockam ersatz\nmea-bridge-main\nmea_bridge\nmea_bridge.ino: In function 'void transmit_outgoing_over_websocket(char, size_t)':
C:\Arduino Ockam ersatz\nmea-bridge-main\nmea_bridge\nmea_bridge.ino:589:50: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
  589 |         send_websocket_message(sentence, length, "serial");
      |                                                  ^~~~~~~~
C:\Arduino Ockam ersatz\nmea-bridge-main\nmea_bridge\nmea_bridge.ino: In function 'void send_websocket_message(char*, size_t, char*)':
C:\Arduino Ockam ersatz\nmea-bridge-main\nmea_bridge\nmea_bridge.ino:603:54: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
  603 |                 write_format_to_http_response_buffer("\u%04x", int(c));
      |                                                      ^~~~~~~~~
. Variables and constants in RAM (global, static), used 42204 / 80192 bytes (52%)
║   SEGMENT  BYTES    DESCRIPTION
╠══ DATA     1632     initialized variables
╠══ RODATA   8668     constants
╚══ BSS      31904    zeroed variables
. Instruction RAM (IRAM_ATTR, ICACHE_RAM_ATTR), used 60863 / 65536 bytes (92%)
║   SEGMENT  BYTES    DESCRIPTION
╠══ ICACHE   32768    reserved space for flash instruction cache
╚══ IRAM     28095    code in IRAM
. Code in flash (default, ICACHE_FLASH_ATTR), used 316280 / 1048576 bytes (30%)
║   SEGMENT  BYTES    DESCRIPTION
╚══ IROM     316280   code in flash
esptool.py v3.0
Serial port COM9
Connecting....
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: 84:0d:8e:a7:73:22
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 358832 bytes to 256751...
Writing at 0x00000000... (6 %)
Writing at 0x00004000... (12 %)
Writing at 0x00008000... (18 %)
Writing at 0x0000c000... (25 %)
Writing at 0x00010000... (31 %)
Writing at 0x00014000... (37 %)
Writing at 0x00018000... (43 %)
Writing at 0x0001c000... (50 %)
Writing at 0x00020000... (56 %)
Writing at 0x00024000... (62 %)
Writing at 0x00028000... (68 %)
Writing at 0x0002c000... (75 %)
Writing at 0x00030000... (81 %)
Writing at 0x00034000... (87 %)
Writing at 0x00038000... (93 %)
Writing at 0x0003c000... (100 %)
Wrote 358832 bytes (256751 compressed) at 0x00000000 in 6.2 seconds (effective 461.7 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...

Gesendet: Mittwoch, 06. Dezember 2023 um 17:02 Uhr
Von: "Alexander van Ratingen" @.>
An: "alvra/nmea-bridge" @.>
Cc: "bbgt0814" @.>, "Author" @.>
Betreff: Re: [alvra/nmea-bridge] can't find the ssid on my network NMEA Bridge (Issue #5)

Did it compile and flash without errors; what was the logging output?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

I tried it with both Arduino IDE Versions 1.8X  and 2.X, the error remains the same. Greetings

Hi, questions about the problem described. on which board was the sketch originally developed? which lib and  which IDE compiler version does the sketch work? Is there currently a board on which the sketch can run?

Hello,
Having a similar issue with HiLetgo NodeMCU LUA ESP8266
Looking through the code, I am getting a double blink which indicates I am in access point mode but there is no SSID showing up on any of my devices.
Any thoughts on where to go from here?

Some information that may be helpful to you:
Original device for which this was developed: NodeMCU v3
Arduino IDE version: 1.8.19 (2021)
Board config in IDE: NodeMCU 1.0 (ESP-12E Module)
If the device was properly flashed and otherwise seems to function but you're not seeing a WiFi access point, it might be that the device is accidentally configured into station mode. Try to reset it as explained in the readme, and see if the AP NMEA Bridge appears.

I've been through everything. I assume that the eeprom is addressed incorrectly.
I gave up the project because all work with the sketch was not productive.
The new IDE no longer works as expected. Process too complex.

Gesendet: Montag, 08. Januar 2024 um 22:42 Uhr
Von: "Alexander van Ratingen" @.>
An: "alvra/nmea-bridge" @.>
Cc: "bbgt0814" @.>, "Author" @.>
Betreff: Re: [alvra/nmea-bridge] can't find the ssid on my network NMEA Bridge (Issue #5)

Some information that may be helpful to you:
Original device for which this was developed: NodeMCU v3
Arduino IDE version: 1.8.19 (2021)
Board config in IDE: NodeMCU 1.0 (ESP-12E Module)
If the device was properly flashed and otherwise seems to function but you're not seeing a WiFi access point, it might be that the device is accidentally configured into station mode. Try to reset it as explained in the readme, and see if the AP NMEA Bridge appears.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

Had the same problem.  The ESP8266 came up with an access point SSID of FARYLINK-*******, password unknown. To cut a long story short, I was not able to reset the module on boot.  So I added a button to an unused GPIO input and changed the code just to check if that button is pressed.  Then bingo, I got the NEMA-Bridge SSID successfully.

please post a working sketch (for nodemcu esp8266). I really need to connect nmea 0183 to wifi

Ok, I've solved my problem. On my board, there are actually two buttons: reset and flash. Pressing the reset button resets the board - nothing else. What actually worked was pressing the flash button!
I hope I'll save some poor soul hours of debugging.


HADOOP-18009. Reset UserGroupInformation after tests run

Description of PR
This pull request aims to reset shared state between TestSecureRegistry and TestRegistryOperationUtils, where TestRegistryOperationUtils (namely testUsernameExtractionEnvVarOverrride) fails when run afterwards in the same JVM. While currently test classes are run in separate JVMs, they can be run faster when run in the same JVM, and the shared state can be reset with the proposed patch in this pull request.
How was this patch tested?
Before this patch, if the two test classes TestSecureRegistry and TestRegistryOperationUtils are run in this order within the same JVM (Surefire configuration reuseForks=true), TestRegistryOperationUtils fails. After the patch, the test passes in the order.
For code changes:

[ ] Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
[ ] Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
1m  4s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  2s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
34m 59s

trunk passed

+1 :green_heart:
compile
23m 35s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
compile
20m  3s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
checkstyle
0m 33s

trunk passed

+1 :green_heart:
mvnsite
0m 36s

trunk passed

+1 :green_heart:
javadoc
0m 35s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
0m 33s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
0m 53s

trunk passed

+1 :green_heart:
shadedclient
23m 19s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 21s

the patch passed

+1 :green_heart:
compile
22m 48s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javac
22m 48s

the patch passed

+1 :green_heart:
compile
19m 56s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
javac
19m 56s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 28s

the patch passed

+1 :green_heart:
mvnsite
0m 34s

the patch passed

+1 :green_heart:
javadoc
0m 34s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
0m 32s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
1m  0s

the patch passed

+1 :green_heart:
shadedclient
23m  8s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
1m 16s

hadoop-registry in the patch passed.

+1 :green_heart:
asflicense
0m 50s

The patch does not generate ASF License warnings.

180m 39s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3656/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/3656

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell

uname
Linux 0ab18b58a42f 4.15.0-142-generic #146-Ubuntu SMP Tue Apr 13 01:11:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 7078ebe55bd90363fe6c8eaa7626f2b94fd722e1

Default Java
Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3656/1/testReport/

Max. process+thread count
524 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-registry U: hadoop-common-project/hadoop-registry

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3656/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.


[Project question] Fails to build Windows executable

Hello,
First of all I am not really competent with binding libraries and cross-compilation.
I am under Ubuntu 20.04.

I use Gotk3 for a project, installed it smoothless. I can build a linux binary without any problem but it seem Go can't find GTK when trying to build for windows executable.

Am I missing something ?
Or does anyone else have this issue ?

I'm sorry if I got it wrong, but I think you're not following the Cross Compile from the wiki.


Connecting to trusting domain in different forest

How do I connect to a trusting domain in different forest? Is there any guidance around it?
I tried to connect to the trusting domain by providing the credentials of my base domain. My user account is created in "Domain_1" which is under "Master_Domain_1". I can authenticate to both these domains. I have Master_Domain_2  which is a separate forest that has "Domain_2" domain.
import bonsai
import configparser

bonsai.set_connect_async(False)

CACERT_FILE = "./Cert/cacerts.pem"

username = 'my_user'
password = 'SecretPassword#'

config = configparser.ConfigParser()
config.read('.//AD_Configs//Config.ini')
server_name = config['DOMAIN_1']['URL']

client = bonsai.LDAPClient(server_name)
client.set_ca_cert(CACERT_FILE)
client.set_auto_page_acquire(True)

client.set_credentials("SIMPLE", user="CN="+username+"OU=Users,DC=DOMAIN_1,DC=com", password=password)

base = config['DOMAIN_1']['Base']

# bonsai.set_connect_async(False)

conn = client.connect()
query = "(&(objectClass=group)(SamAccountName=Domain Admins))"

list_of_attributes = ['*']
final_result = []

with client.connect() as conn:
    result = conn.paged_search(base=base, scope=2, filter_exp=query, attrlist=['*'],
                               page_size=1000, attrsonly=False)
    for r in result:
        final_result.append(r)
    print(len(final_result))
    msgid = result.acquire_next_page()
    while msgid is not None:
        result = conn._evaluate(msgid)
        for r in result:
            final_result.append(r)
        msgid = result.acquire_next_page()

print(len(final_result))

This code is successful when I change the DOMAIN_1 to Master_Domain_1 as well. When I change the server_name to reference the Domain_2 or Master_Domain_2 (also changed the base variable) where I have bi-directional trust I am not able to authenticate and I get the following error for conn = client.connect()-
bonsai.errors.AuthenticationError: Invalid credentials. 80090308: LdapErr: DSID-0C090447, comment: AcceptSecurityContext error, data 52e, v3839 (0x0031 [49])
The debug logs are -
DBG: ldapconnection_new [self:0x11790b760]
DBG: ldapconnection_init (self:0x11790b760)
DBG: ldapconnection_open (self:0x11790b760)
DBG: connecting (self:0x11790b760)
DBG: create_conn_info (mech:SIMPLE, sock:-1, creds:0x117905600)
DBG: ldapconnectiter_new [self:0x117916300]
DBG: create_init_thread_data (client:0x1178f6c40, sock:-1)
DBG: create_init_thread (ld:0x7fbba9ae51b0, info:0x7fbba9ae5b60, thread:0)
DBG: ldapconnection_result (self:0x11790b760, args:0x1162f0300, kwds:0x0)[msgid:-1]
DBG: LDAPConnection_Result (self:0x11790b760, msgid:-1, millisec:-1)
DBG: LDAPConnectIter_Next (self:0x117916300, timeout:-1) [tls:0, state:0]
DBG: _ldap_finish_init_thread (async:0, thread:123145512566784, timeout:-1, misc:0x7fbba9ae51b0)
DBG: ldap_init_thread_func (params:0x7fbba9ae51b0)
DBG: _pthread_mutex_timedlock
DBG: set connecting async: 0
DBG: ldap_init_thread_func [retval:0]
ldap_create
ldap_url_parse_ext(ldaps://domain_2.com:636)
DBG: set_certificates (self:0x117916300)
DBG: binding [state:3]
ldap_sasl_bind
DBG: _ldap_bind (ld:0x7fbba9a77110, info:0x7fbba9ae5b60, ppolicy:0, result:0x0, msgid:0)
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP domain_2.com:636
ldap_new_socket: 7
ldap_prepare_socket: 7
ldap_connect_to_host: Trying <IP_ADDRESS>:636
ldap_pvt_connect: fd: 7 tm: -1 async: 0
attempting to connect:
connect success
TLS trace: SSL_connect:before SSL initialization
TLS trace: SSL_connect:SSLv3/TLS write client hello
TLS trace: SSL_connect:SSLv3/TLS write client hello
TLS trace: SSL_connect:SSLv3/TLS read server hello
TLS certificate verification: depth: 3, err: 0, subject:
TLS certificate verification: depth: 2, err: 0, subject:
TLS certificate verification: depth: 1, err: 0, subject:
TLS certificate verification: depth: 0, err: 0, subject:
TLS trace: SSL_connect:SSLv3/TLS read server certificate
TLS trace: SSL_connect:SSLv3/TLS read server key exchange
TLS trace: SSL_connect:SSLv3/TLS read server certificate request
TLS trace: SSL_connect:SSLv3/TLS read server done
TLS trace: SSL_connect:SSLv3/TLS write client certificate
TLS trace: SSL_connect:SSLv3/TLS write client key exchange
TLS trace: SSL_connect:SSLv3/TLS write change cipher spec
TLS trace: SSL_connect:SSLv3/TLS write finished
TLS trace: SSL_connect:SSLv3/TLS write finished
TLS trace: SSL_connect:SSLv3/TLS read change cipher spec
TLS trace: SSL_connect:SSLv3/TLS read finished
ldap_open_defconn: successful
ldap_send_server_request
ldap_msgfree
DBG: LDAPConnectIter_Next (self:0x117916300, timeout:-1) [tls:0, state:4]
DBG: binding [state:4]
ldap_result ld 0x7fbba9a77110 msgid 1
wait4msg ld 0x7fbba9a77110 msgid 1 (infinite timeout)
wait4msg continue ld 0x7fbba9a77110 msgid 1 all 1
** ld 0x7fbba9a77110 Connections:
* host: domain_2.com  port: 636  (default)
  refcnt: 2  status: Connected
  last used: Tue Aug 10 14:54:56 2021
** ld 0x7fbba9a77110 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x7fbba9a77110 request count 1 (abandoned 0)
** ld 0x7fbba9a77110 Response Queue:
   Empty
  ld 0x7fbba9a77110 response count 0
ldap_chkResponseList ld 0x7fbba9a77110 msgid 1 all 1
ldap_chkResponseList returns ld 0x7fbba9a77110 NULL
ldap_int_select
read1msg: ld 0x7fbba9a77110 msgid 1 all 1
read1msg: ld 0x7fbba9a77110 msgid 1 message type bind
read1msg: ld 0x7fbba9a77110 0 new referrals
read1msg:  mark request completed, ld 0x7fbba9a77110 msgid 1
request done: ld 0x7fbba9a77110 msgid 1
res_errno: 49, res_error: <80090308: LdapErr: DSID-0C090447, comment: AcceptSecurityContext error, data 52e, v3839>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_parse_result
ldap_msgfree
ldap_err2string
DBG: ldapconnectiter_dealloc (self:0x117916300)
DBG: dealloc_conn_info (info:0x7fbba9ae5b60)
DBG: ldapconnection_dealloc (self:0x11790b520)
ldap_free_connection 1 1
ldap_send_unbind
TLS trace: SSL3 alert write:warning:close notify
ldap_free_connection: actually freed

What should I do differently ?  I kept the user identity to my original domain_1 id and password as I use the same to authenticate with Powershell. (but RSAT module code be doing something in the background)

Is there a way bind to AD by generating token through Kerberos?

You can try using GSSAPI or GSS-SPNEGO SASL mechanisms instead of SIMPLE.
But unfortunately, I have no experience with AD forests.

@noirello Yes you are right. I tried GSSAPI using client.set_credentials("GSSAPI", user='user_sam_account_name', password=password, realm = 'domain.com') but I get error - bonsai.errors.LDAPError: Local error. SASL(-1): generic failure: GSSAPI Error:  Miscellaneous failure (see text (no credential for XXXXXXXX) (0xFFFE [-2])  I did kdestroy before running the command and checked if there were any tickets before and after running the python script. No tickets were generated.

Are you able to authenticate using kinit in command line? There's an example in the docs. If the ticket is valid for LDAP auth, bonsai should be able to use it.

@noirello  yes I am able to do that from command line but would that be not possible through the script and use that for the connection?
Also when I manually generate the ticket using the kinit command I get the following -
DBG: ldapconnection_new [self:0x104563d00]
DBG: ldapconnection_init (self:0x104563d00)
DBG: ldapconnection_open (self:0x104563d00)
DBG: connecting (self:0x104563d00)
DBG: create_conn_info (mech:GSSAPI, sock:-1, creds:0x104748dc0)
DBG: ldapconnectiter_new [self:0x10474bb20]
DBG: create_init_thread_data (client:0x10453bc70, sock:-1)
DBG: create_init_thread (ld:0x7fa9eacdeea0, info:0x7fa9eacfb3e0, thread:0)
DBG: ldapconnection_result (self:0x104563d00, args:0x104566f80, kwds:0x0)[msgid:-1]
DBG: LDAPConnection_Result (self:0x104563d00, msgid:-1, millisec:-1)
DBG: LDAPConnectIter_Next (self:0x10474bb20, timeout:-1) [tls:0, state:0]
DBG: _ldap_finish_init_thread (async:0, thread:123145473105920, timeout:-1, misc:0x7fa9eacdeea0)
DBG: _pthread_mutex_timedlock
DBG: ldap_init_thread_func (params:0x7fa9eacdeea0)
DBG: set connecting async: 0
DBG: ldap_init_thread_func [retval:0]
ldap_create
ldap_url_parse_ext(ldaps://domain.com:636)
DBG: LDAPConnectIter_Next (self:0x10474bb20, timeout:-1) [tls:0, state:0]
DBG: _ldap_finish_init_thread (async:0, thread:123145473105920, timeout:-1, misc:0x7fa9eacdeea0)
DBG: _pthread_mutex_timedlock
DBG: set_certificates (self:0x10474bb20)
DBG: binding [state:3]
ldap_sasl_interactive_bind: user selected: GSSAPI
DBG: _ldap_bind (ld:0x7fa9ec11c260, info:0x7fa9eacfb3e0, ppolicy:0, result:0x0, msgid:0)
ldap_int_sasl_bind: GSSAPI
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP domain.com:636
ldap_new_socket: 8
ldap_prepare_socket: 8
ldap_connect_to_host: Trying <IP_ADDRESS>:636
ldap_pvt_connect: fd: 8 tm: -1 async: 0
attempting to connect:
connect success
TLS trace: SSL_connect:before SSL initialization
TLS trace: SSL_connect:SSLv3/TLS write client hello
TLS trace: SSL_connect:SSLv3/TLS write client hello
TLS trace: SSL_connect:SSLv3/TLS read server hello
TLS certificate verification: depth: 3, err: 0, subject:
TLS certificate verification: depth: 2, err: 0, subject:
TLS certificate verification: depth: 1, err: 0, subject:
TLS certificate verification: depth: 0, err: 0, subject:
TLS trace: SSL_connect:SSLv3/TLS read server certificate
TLS trace: SSL_connect:SSLv3/TLS read server key exchange
TLS trace: SSL_connect:SSLv3/TLS read server certificate request
TLS trace: SSL_connect:SSLv3/TLS read server done
TLS trace: SSL_connect:SSLv3/TLS write client certificate
TLS trace: SSL_connect:SSLv3/TLS write client key exchange
TLS trace: SSL_connect:SSLv3/TLS write change cipher spec
TLS trace: SSL_connect:SSLv3/TLS write finished
TLS trace: SSL_connect:SSLv3/TLS write finished
TLS trace: SSL_connect:SSLv3/TLS read change cipher spec
TLS trace: SSL_connect:SSLv3/TLS read finished
DBG: sasl_interact (ld:0x7fa9ec11c260, flags:2, defs:0x7fa9eacfb3e0, in:0x7fa9ef82da40)
ldap_int_sasl_open: host=server.domain.com
ldap_sasl_bind
ldap_send_initial_request
ldap_send_server_request
ldap_msgfree
ldap_result ld 0x7fa9ec11c260 msgid 1
wait4msg ld 0x7fa9ec11c260 msgid 1 (infinite timeout)
wait4msg continue ld 0x7fa9ec11c260 msgid 1 all 1
** ld 0x7fa9ec11c260 Connections:
* host: domain.com  port: 636  (default)
  refcnt: 2  status: Connected
DBG: LDAPConnectIter_Next (self:0x10474bb20, timeout:-1) [tls:0, state:4]
DBG: binding [state:4]
  last used: Mon Aug 16 09:46:12 2021
** ld 0x7fa9ec11c260 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x7fa9ec11c260 request count 1 (abandoned 0)
** ld 0x7fa9ec11c260 Response Queue:
   Empty
  ld 0x7fa9ec11c260 response count 0
ldap_chkResponseList ld 0x7fa9ec11c260 msgid 1 all 1
ldap_chkResponseList returns ld 0x7fa9ec11c260 NULL
ldap_int_select
read1msg: ld 0x7fa9ec11c260 msgid 1 all 1
DBG: _ldap_bind (ld:0x7fa9ec11c260, info:0x7fa9eacfb3e0, ppolicy:0, result:0x7fa9ef820740, msgid:1)
read1msg: ld 0x7fa9ec11c260 msgid 1 message type bind
read1msg: ld 0x7fa9ec11c260 0 new referrals
read1msg:  mark request completed, ld 0x7fa9ec11c260 msgid 1
request done: ld 0x7fa9ec11c260 msgid 1
res_errno: 14, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_parse_result
ldap_int_sasl_bind: GSSAPI
ldap_parse_sasl_bind_result
ldap_parse_result
sasl_client_step: 1
ldap_sasl_bind
ldap_send_initial_request
ldap_send_server_request
DBG: LDAPConnectIter_Next (self:0x10474bb20, timeout:-1) [tls:0, state:4]
DBG: binding [state:4]
ldap_msgfree
ldap_result ld 0x7fa9ec11c260 msgid 2
wait4msg ld 0x7fa9ec11c260 msgid 2 (infinite timeout)
wait4msg continue ld 0x7fa9ec11c260 msgid 2 all 1
** ld 0x7fa9ec11c260 Connections:
* host: domain.com  port: 636  (default)
  refcnt: 2  status: Connected
  last used: Mon Aug 16 09:46:12 2021
** ld 0x7fa9ec11c260 Outstanding Requests:
 * msgid 2,  origid 2, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x7fa9ec11c260 request count 1 (abandoned 0)
** ld 0x7fa9ec11c260 Response Queue:
   Empty
  ld 0x7fa9ec11c260 response count 0
ldap_chkResponseList ld 0x7fa9ec11c260 msgid 2 all 1
ldap_chkResponseList returns ld 0x7fa9ec11c260 NULL
ldap_int_select
read1msg: ld 0x7fa9ec11c260 msgid 2 all 1
read1msg: ld 0x7fa9ec11c260 msgid 2 message type bind
read1msg: ld 0x7fa9ec11c260 0 new referrals
read1msg:  mark request completed, ld 0x7fa9ec11c260 msgid 2
request done: ld 0x7fa9ec11c260 msgid 2
res_errno: 14, res_error: <>, res_matched: <>
DBG: _ldap_bind (ld:0x7fa9ec11c260, info:0x7fa9eacfb3e0, ppolicy:0, result:0x7fa9ec7fa0f0, msgid:2)
ldap_free_request (origid 2, msgid 2)
ldap_parse_result
ldap_int_sasl_bind: GSSAPI
ldap_parse_sasl_bind_result
ldap_parse_result
sasl_client_step: 0
ldap_sasl_bind
ldap_send_initial_request
ldap_send_server_request
DBG: LDAPConnectIter_Next (self:0x10474bb20, timeout:-1) [tls:0, state:4]
DBG: binding [state:4]
ldap_msgfree
ldap_result ld 0x7fa9ec11c260 msgid 3
wait4msg ld 0x7fa9ec11c260 msgid 3 (infinite timeout)
wait4msg continue ld 0x7fa9ec11c260 msgid 3 all 1
** ld 0x7fa9ec11c260 Connections:
* host: domain.com  port: 636  (default)
  refcnt: 2  status: Connected
  last used: Mon Aug 16 09:46:12 2021
** ld 0x7fa9ec11c260 Outstanding Requests:
 * msgid 3,  origid 3, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x7fa9ec11c260 request count 1 (abandoned 0)
** ld 0x7fa9ec11c260 Response Queue:
   Empty
  ld 0x7fa9ec11c260 response count 0
ldap_chkResponseList ld 0x7fa9ec11c260 msgid 3 all 1
ldap_chkResponseList returns ld 0x7fa9ec11c260 NULL
ldap_int_select
read1msg: ld 0x7fa9ec11c260 msgid 3 all 1
read1msg: ld 0x7fa9ec11c260 msgid 3 message type bind
DBG: _ldap_bind (ld:0x7fa9ec11c260, info:0x7fa9eacfb3e0, ppolicy:0, result:0x7fa9ec05eb80, msgid:3)
read1msg: ld 0x7fa9ec11c260 0 new referrals
DBG: ldapconnectiter_dealloc (self:0x10474bb20)
read1msg:  mark request completed, ld 0x7fa9ec11c260 msgid 3
DBG: dealloc_conn_info (info:0x7fa9eacfb3e0)
request done: ld 0x7fa9ec11c260 msgid 3
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 3, msgid 3)
ldap_parse_result
ldap_int_sasl_bind: GSSAPI
ldap_parse_sasl_bind_result
ldap_parse_result
ldap_pvt_sasl_generic_install
ldap_msgfree
DBG: ldapconnection_dealloc (self:0x104563be0)
ldap_free_connection 1 1
ldap_send_unbind
TLS trace: SSL3 alert write:warning:close notify
ldap_free_connection: actually freed
DBG: ldapconnection_search (self:0x104563d00, args:0x1044f8c20, kwds:0x0)
DBG: LDAPConnection_IsClosed (self:0x104563d00)
DBG: ldapsearchiter_new [self:0x103e92df0]
DBG: LDAPSearchIter_New (conn:0x104563d00)[self:0x103e92df0]
DBG: LDAPConnection_Searching (self:0x104563d00, params_in:0x7ffeed1f3ab8, iterator:0x103e92df0)
ldap_search_ext
put_filter: "(&(objectClass=group)(SamAccountName=Group_NAME))"
put_filter: AND
put_filter_list "(objectClass=group)(SamAccountName=Group_NAME)"
put_filter: "(objectClass=group)"
put_filter: simple
put_simple_filter: "objectClass=group"
put_filter: "(SamAccountName=Group_NAME)"
put_filter: simple
put_simple_filter: "SamAccountName=Group_NAME"
ldap_build_search_req ATTRS: *
ldap_send_initial_request
DBG: ldapconnection_result (self:0x104563d00, args:0x104566f80, kwds:0x0)[msgid:4]
ldap_send_server_request
DBG: LDAPConnection_Result (self:0x104563d00, msgid:4, millisec:-1)
ldap_result ld 0x7fa9ec11c260 msgid 4
wait4msg ld 0x7fa9ec11c260 msgid 4 (infinite timeout)
wait4msg continue ld 0x7fa9ec11c260 msgid 4 all 1
** ld 0x7fa9ec11c260 Connections:
* host: domain.com  port: 636  (default)
  refcnt: 2  status: Connected
  last used: Mon Aug 16 09:46:12 2021
** ld 0x7fa9ec11c260 Outstanding Requests:
 * msgid 4,  origid 4, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x7fa9ec11c260 request count 1 (abandoned 0)
** ld 0x7fa9ec11c260 Response Queue:
   Empty
  ld 0x7fa9ec11c260 response count 0
ldap_chkResponseList ld 0x7fa9ec11c260 msgid 4 all 1
ldap_chkResponseList returns ld 0x7fa9ec11c260 NULL
ldap_int_select
read1msg: ld 0x7fa9ec11c260 msgid 4 all 1
ber_get_next failed, errno=5.
ldap_err2string
DBG: ldapconnection_close (self:0x104563d00)
ldap_abandon_ext 4
do_abandon origid 4, msgid 4
ldap_msgdelete ld=0x7fa9ec11c260 msgid=4
ldap_free_request (origid 4, msgid 4)
ldap_free_connection 0 1
ldap_free_connection: actually freed
ldap_err2string
DBG: ldapconnection_dealloc (self:0x10452b520)
Traceback (most recent call last):
  File "<input>", line 23, in <module>
  File "/Active_Directory/venv/lib/python3.9/site-packages/bonsai/ldapconnection.py", line 329, in paged_search
    return super().paged_search(
  File "/Active_Directory/venv/lib/python3.9/site-packages/bonsai/ldapconnection.py", line 169, in paged_search
    return self.__base_search(
  File "/Active_Directory/venv/lib/python3.9/site-packages/bonsai/ldapconnection.py", line 111, in __base_search
    return self._evaluate(msg_id, timeout)
  File "//Active_Directory/venv/lib/python3.9/site-packages/bonsai/ldapconnection.py", line 246, in _evaluate
    return self.get_result(msg_id, timeout)
bonsai.errors.ConnectionError: Can't contact LDAP server. (0xFFFF [-1])
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "<input>", line 33, in <module>
  File "/Active_Directory/venv/lib/python3.9/site-packages/bonsai/ldapconnection.py", line 37, in __exit__
    self.close()
bonsai.errors.ConnectionError: Can't contact LDAP server. (0xFFFF [-1])

Could you share the example code when you trying to use the pre-aquired ticket?
And the output of  bonsai.has_krb5_support() also would be great.

import bonsai
import configparser

bonsai.set_connect_async(False)

CACERT_FILE = "./Cert/cacerts.pem"

username = 'my_user'
password = 'SecretPassword#'

config = configparser.ConfigParser()
config.read('.//AD_Configs//Config.ini')
server_name = config['DOMAIN_1']['URL'] # 'domain.com'

client = bonsai.LDAPClient(server_name)
client.set_ca_cert(CACERT_FILE)
client.set_auto_page_acquire(True)

client.set_credentials("GSSAPI", user=username, password=password, realm = server_name)

base = "DC=DOMAIN_1,DC=com"

bonsai.set_connect_async(False)

conn = client.connect()
query = "(&(objectClass=group)(SamAccountName=Group_NAME))"

list_of_attributes = ['*']
final_result = []

with client.connect() as conn:
    result = conn.paged_search(base=base, scope=2, filter_exp=query, attrlist=['*'],
                               page_size=1000, attrsonly=False)
    for r in result:
        final_result.append(r)
    print(len(final_result))
    msgid = result.acquire_next_page()
    while msgid is not None:
        result = conn._evaluate(msgid)
        for r in result:
            final_result.append(r)
        msgid = result.acquire_next_page()

print(len(final_result))

Output for the bonsai.has_krb5_support()
False

The module hasn't been built with Kerberos support, so it's not possible to acquire a ticket from inside the script. But using kinit should work.
Could you try to run a more simple script? Something like this:
import bonsai
import configparser

bonsai.set_debug(True, -1)
bonsai.set_connect_async(False)

CACERT_FILE = "./Cert/cacerts.pem"

config = configparser.ConfigParser()
config.read('.//AD_Configs//Config.ini')
server_name = config['DOMAIN_1']['URL'] # 'domain.com'

client = bonsai.LDAPClient(server_name)
client.set_ca_cert(CACERT_FILE)
client.set_credentials("GSSAPI")

with client.connect() as conn:
    print(conn.whoami())

Run kinit for getting a ticket, then this script.

I got the ticket and ran the script. Here are the logs -
DBG: ldapconnection_new [self:0x102430400]
DBG: ldapconnection_init (self:0x102430400)
DBG: ldapconnection_open (self:0x102430400)
DBG: connecting (self:0x102430400)
DBG: create_conn_info (mech:GSSAPI, sock:-1, creds:0x102410900)
DBG: ldapconnectiter_new [self:0x102427a30]
DBG: create_init_thread_data (client:0x10240fd60, sock:-1)
DBG: create_init_thread (ld:0x7fcec385e6c0, info:0x7fcec383b740, thread:0)
DBG: ldapconnection_result (self:0x102430400, args:0x101cfb2c0, kwds:0x0)[msgid:-1]
DBG: DBG: LDAPConnection_Result (self:0x102430400, msgid:-1, millisec:-1)
DBG: LDAPConnectIter_Next (self:0x102427a30, timeout:-1) [tls:0, state:0]
DBG: _ldap_finish_init_thread (async:0, thread:123145480474624, timeout:-1, misc:0x7fcec385e6c0)
ldap_init_thread_func (params:0x7fcec385e6c0)
DBG: _pthread_mutex_timedlock
ldap_create
ldap_url_parse_ext(ldaps://domain.com:636)
DBG: set connecting async: 0
DBG: ldap_init_thread_func [retval:0]
DBG: set_certificates (self:0x102427a30)
DBG: binding [state:3]
DBG: _ldap_bind (ld:0x7fcec3c202b0, info:0x7fcec383b740, ppolicy:0, result:0x0, msgid:0)
ldap_sasl_interactive_bind: user selected: GSSAPI
ldap_int_sasl_bind: GSSAPI
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP domain.com:636
ldap_new_socket: 7
ldap_prepare_socket: 7
ldap_connect_to_host: Trying 10.X.X.X:636
ldap_pvt_connect: fd: 7 tm: -1 async: 0
attempting to connect:
connect success
TLS trace: SSL_connect:before SSL initialization
TLS trace: SSL_connect:SSLv3/TLS write client hello
TLS trace: SSL_connect:SSLv3/TLS write client hello
TLS trace: SSL_connect:SSLv3/TLS read server hello
TLS certificate verification: depth: 3, err: 0, subject:
TLS certificate verification: depth: 2, err: 0, subject:
TLS certificate verification: depth: 1, err: 0, subject:
TLS certificate verification: depth: 0, err: 0, subject:
TLS trace: SSL_connect:SSLv3/TLS read server certificate
TLS trace: SSL_connect:SSLv3/TLS read server key exchange
TLS trace: SSL_connect:SSLv3/TLS read server certificate request
TLS trace: SSL_connect:SSLv3/TLS read server done
TLS trace: SSL_connect:SSLv3/TLS write client certificate
TLS trace: SSL_connect:SSLv3/TLS write client key exchange
TLS trace: SSL_connect:SSLv3/TLS write change cipher spec
TLS trace: SSL_connect:SSLv3/TLS write finished
TLS trace: SSL_connect:SSLv3/TLS write finished
TLS trace: SSL_connect:SSLv3/TLS read change cipher spec
TLS trace: SSL_connect:SSLv3/TLS read finished
ldap_int_sasl_open: host=server.domain.com
DBG: sasl_interact (ld:0x7fcec3c202b0, flags:2, defs:0x7fcec383b740, in:0x7fcec1fedeb0)
ldap_sasl_bind
ldap_send_initial_request
ldap_send_server_request
DBG: LDAPConnectIter_Next (self:0x102427a30, timeout:-1) [tls:0, state:4]
DBG: binding [state:4]
ldap_msgfree
ldap_result ld 0x7fcec3c202b0 msgid 1
wait4msg ld 0x7fcec3c202b0 msgid 1 (infinite timeout)
wait4msg continue ld 0x7fcec3c202b0 msgid 1 all 1
** ld 0x7fcec3c202b0 Connections:
* host: domain.com  port: 636  (default)
  refcnt: 2  status: Connected
  last used: Mon Aug 16 12:12:15 2021
** ld 0x7fcec3c202b0 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x7fcec3c202b0 request count 1 (abandoned 0)
** ld 0x7fcec3c202b0 Response Queue:
   Empty
  ld 0x7fcec3c202b0 response count 0
ldap_chkResponseList ld 0x7fcec3c202b0 msgid 1 all 1
ldap_chkResponseList returns ld 0x7fcec3c202b0 NULL
ldap_int_select
read1msg: ld 0x7fcec3c202b0 msgid 1 all 1
read1msg: ld 0x7fcec3c202b0 msgid 1 message type bind
read1msg: ld 0x7fcec3c202b0 0 new referrals
DBG: _ldap_bind (ld:0x7fcec3c202b0, info:0x7fcec383b740, ppolicy:0, result:0x7fcec1fed910, msgid:1)
read1msg:  mark request completed, ld 0x7fcec3c202b0 msgid 1
request done: ld 0x7fcec3c202b0 msgid 1
res_errno: 14, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_parse_result
ldap_int_sasl_bind: GSSAPI
ldap_parse_sasl_bind_result
ldap_parse_result
sasl_client_step: 1
ldap_sasl_bind
ldap_send_initial_request
ldap_send_server_request
DBG: LDAPConnectIter_Next (self:0x102427a30, timeout:-1) [tls:0, state:4]
ldap_msgfree
DBG: binding [state:4]
ldap_result ld 0x7fcec3c202b0 msgid 2
wait4msg ld 0x7fcec3c202b0 msgid 2 (infinite timeout)
wait4msg continue ld 0x7fcec3c202b0 msgid 2 all 1
** ld 0x7fcec3c202b0 Connections:
* host: domain.com  port: 636  (default)
  refcnt: 2  status: Connected
  last used: Mon Aug 16 12:12:15 2021
** ld 0x7fcec3c202b0 Outstanding Requests:
 * msgid 2,  origid 2, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x7fcec3c202b0 request count 1 (abandoned 0)
** ld 0x7fcec3c202b0 Response Queue:
   Empty
  ld 0x7fcec3c202b0 response count 0
ldap_chkResponseList ld 0x7fcec3c202b0 msgid 2 all 1
ldap_chkResponseList returns ld 0x7fcec3c202b0 NULL
ldap_int_select
read1msg: ld 0x7fcec3c202b0 msgid 2 all 1
read1msg: ld 0x7fcec3c202b0 msgid 2 message type bind
read1msg: ld 0x7fcec3c202b0 0 new referrals
read1msg:  mark request completed, ld 0x7fcec3c202b0 msgid 2
request done: ld 0x7fcec3c202b0 msgid 2
DBG: _ldap_bind (ld:0x7fcec3c202b0, info:0x7fcec383b740, ppolicy:0, result:0x7fcec1c6cfd0, msgid:2)
res_errno: 14, res_error: <>, res_matched: <>
ldap_free_request (origid 2, msgid 2)
ldap_parse_result
ldap_int_sasl_bind: GSSAPI
ldap_parse_sasl_bind_result
ldap_parse_result
sasl_client_step: 0
ldap_sasl_bind
ldap_send_initial_request
ldap_send_server_request
DBG: LDAPConnectIter_Next (self:0x102427a30, timeout:-1) [tls:0, state:4]
DBG: binding [state:4]
ldap_msgfree
ldap_result ld 0x7fcec3c202b0 msgid 3
wait4msg ld 0x7fcec3c202b0 msgid 3 (infinite timeout)
wait4msg continue ld 0x7fcec3c202b0 msgid 3 all 1
** ld 0x7fcec3c202b0 Connections:
* host: domain  port: 636  (default)
  refcnt: 2  status: Connected
  last used: Mon Aug 16 12:12:15 2021
** ld 0x7fcec3c202b0 Outstanding Requests:
 * msgid 3,  origid 3, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x7fcec3c202b0 request count 1 (abandoned 0)
** ld 0x7fcec3c202b0 Response Queue:
   Empty
  ld 0x7fcec3c202b0 response count 0
ldap_chkResponseList ld 0x7fcec3c202b0 msgid 3 all 1
ldap_chkResponseList returns ld 0x7fcec3c202b0 NULL
ldap_int_select
read1msg: ld 0x7fcec3c202b0 msgid 3 all 1
read1msg: ld 0x7fcec3c202b0 msgid 3 message type bind
read1msg: ld 0x7fcec3c202b0 0 new referrals
read1msg:  mark request completed, ld 0x7fcec3c202b0 msgid 3
request done: ld 0x7fcec3c202b0 msgid 3
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 3, msgid 3)
ldap_parse_result
DBG: _ldap_bind (ld:0x7fcec3c202b0, info:0x7fcec383b740, ppolicy:0, result:0x7fcec1c6cfd0, msgid:3)
DBG: ldapconnectiter_dealloc (self:0x102427a30)
ldap_int_sasl_bind: GSSAPI
DBG: dealloc_conn_info (info:0x7fcec383b740)
ldap_parse_sasl_bind_result
ldap_parse_result
ldap_pvt_sasl_generic_install
ldap_msgfree
DBG: ldapconnection_whoami (self:0x102430400)
DBG: LDAPConnection_IsClosed (self:0x102430400)
ldap_extended_operation
ldap_send_initial_request
ldap_send_server_request
DBG: ldapconnection_result (self:0x102430400, args:0x101cfb2c0, kwds:0x0)[msgid:4]
DBG: LDAPConnection_Result (self:0x102430400, msgid:4, millisec:-1)
ldap_result ld 0x7fcec3c202b0 msgid 4
wait4msg ld 0x7fcec3c202b0 msgid 4 (infinite timeout)
wait4msg continue ld 0x7fcec3c202b0 msgid 4 all 1
** ld 0x7fcec3c202b0 Connections:
* host: domain.com  port: 636  (default)
  refcnt: 2  status: Connected
  last used: Mon Aug 16 12:12:15 2021
** ld 0x7fcec3c202b0 Outstanding Requests:
 * msgid 4,  origid 4, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x7fcec3c202b0 request count 1 (abandoned 0)
** ld 0x7fcec3c202b0 Response Queue:
   Empty
  ld 0x7fcec3c202b0 response count 0
ldap_chkResponseList ld 0x7fcec3c202b0 msgid 4 all 1
ldap_chkResponseList returns ld 0x7fcec3c202b0 NULL
ldap_int_select
read1msg: ld 0x7fcec3c202b0 msgid 4 all 1
ber_get_next failed, errno=5.
ldap_err2string
DBG: ldapconnection_close (self:0x102430400)
ldap_abandon_ext 4
do_abandon origid 4, msgid 4
ldap_msgdelete ld=0x7fcec3c202b0 msgid=4
ldap_free_request (origid 4, msgid 4)
ldap_free_connection 0 1
ldap_free_connection: actually freed
ldap_err2string
Traceback (most recent call last):
  File "<input>", line 6, in <module>
  File "/Active_Directory/venv/lib/python3.9/site-packages/bonsai/ldapconnection.py", line 405, in whoami
    return super().whoami(timeout)
  File "/Active_Directory/venv/lib/python3.9/site-packages/bonsai/ldapconnection.py", line 221, in whoami
    return self._evaluate(super().whoami(), timeout)
  File "/Active_Directory/venv/lib/python3.9/site-packages/bonsai/ldapconnection.py", line 246, in _evaluate
    return self.get_result(msg_id, timeout)
bonsai.errors.ConnectionError: Can't contact LDAP server. (0xFFFF [-1])
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "<input>", line 6, in <module>
  File "/Active_Directory/venv/lib/python3.9/site-packages/bonsai/ldapconnection.py", line 37, in __exit__
    self.close()
bonsai.errors.ConnectionError: Can't contact LDAP server. (0xFFFF [-1])

I can rebuild the module with Kerberos on my mac using the guide https://bonsai.readthedocs.io/en/latest/install.html, what is the path that I need to include in the stepup.cfg for kerberos? (for either package libkrb5-dev or heimdal-dev)

I've just realized that you cannot compile the module with Kerberos support on Mac. :(
You can install heimdal with brew, but they've just recently added the required functionality to acquire a TGT and it's not released yet.

No problem @noirello . I will install heimdal I think their version 7.7.0 for mac and keep an eye out for further updates.
For windows and for Linux this should work right ?
On trying this on a windows 10 machine the same code generates -
DBG: ldapconnection_new [self:000001BC571DB820]
DBG: ldapconnection_init (self:000001BC571DB820)
DBG: ldapconnection_open (self:000001BC571DB820)
DBG: connecting (self:000001BC571DB820)
DBG: create_conn_info (mech:GSSAPI, sock:-1, creds:000001BC571FB740)
DBG: ldapconnectiter_new [self:000001BC571EECB0]
DBG: create_init_thread_data (client:000001BC56FC8FD0, sock:-1)
DBG: create_init_thread (ld:000001BC5695FBE0, info:000001BC569940C0, thread:0)
DBG: ldapconnection_result (self:000001BC571DB820, args:000001BC56F18940, kwds:0000000000000000)[msgid:-1]
DBG: LDAPConnection_Result (self:000001BC571DB820, msgid:-1, millisec:-1)
DBG: LDAPConnectIter_Next (self:000001BC571EECB0, timeout:-1) [tls:0, state:0]
DBG: _ldap_finish_init_thread (async:0, thread:0000000000001398, timeout:-1, misc:000001BC5695FBE0)
DBG: ldap_init_thread_func (params:000001BC5695FBE0)
DBG: ldap_init_thread_func [retval:0]
DBG: binding [state:3]
DBG: _ldap_bind (ld:000001BC5691FC18, info:000001BC569940C0, ppolicy:0, result:0000000000000000, msgid:0)
DBG: LDAPConnectIter_Next (self:000001BC571EECB0, timeout:-1) [tls:0, state:4]
DBG: binding [state:4]
DBG: ldap_thread_bind (params:000001BC569940C0)
DBG: ldapconnectiter_dealloc (self:000001BC571EECB0)
DBG: dealloc_conn_info (info:000001BC569940C0)
DBG: ldapconnection_dealloc (self:000001BC571DB220)
Traceback (most recent call last):
  File "<input>", line 16, in <module>
  File "C:\Users\jack\PycharmProjects\AD\venv\lib\site-packages\bonsai\ldapclient.py", line 588, in connect
    return LDAPConnection(self).open(timeout)
  File "C:\Users\jack\PycharmProjects\AD\venv\lib\site-packages\bonsai\ldapconnection.py", line 297, in open
    return super().open(timeout)
  File "C:\Users\jack\PycharmProjects\AD\venv\lib\site-packages\bonsai\ldapconnection.py", line 53, in open
    return self._evaluate(super().open(), timeout)
  File "C:\Users\jack\PycharmProjects\AD\venv\lib\site-packages\bonsai\ldapconnection.py", line 246, in _evaluate
    return self.get_result(msg_id, timeout)
bonsai.errors.AuthenticationError: Invalid Credentials. (0x0031 [49])

The packages that I have are -
bonsai==1.2.1
cffi==1.14.6
cryptography==3.4.7
decorator==5.0.9
dnspython==2.1.0
gssapi==1.6.14
pyasn1==0.4.8
pycparser==2.20

I've just realized that you cannot compile the module with Kerberos support on Mac. :(

Never mind. You can install brew install krb5 for MIT Kerberos, then update the include and lib dirs in setup.cfg:
[build_ext]
include_dirs=/usr/local/opt/openldap/include:/usr/local/opt/krb5/include
library_dirs=/usr/local/opt/openldap/lib:/usr/local/opt/krb5/lib

But something still goes wrong on Mac, it fails to use the Kerberos ticket.

For windows and for Linux this should work right ?

Yes, it should. But you always have to set the user, password and realm params on Windows.

I had the krb5 library installed and I will recompile bonsai and let you know the results.
As for windows I did pass the credentials (not the ones that I was logged on with on the system) in the set_credentials following is the script and the debug logs -
 import bonsai
import configparser

bonsai.set_debug(True, -1)
bonsai.set_connect_async(False)

CACERT_FILE = "./Cert/cacerts.pem"

config = configparser.ConfigParser()
config.read('.//AD_Configs//Config.ini')
server_name = config['DOMAIN_1']['URL'] # 'ldaps://domain.com'
username = 'my_user'
password = 'SecretPassword#'
realm = config['Domain']['Domain']  # "domain.com"

client = bonsai.LDAPClient(server_name)
client.set_ca_cert(CACERT_FILE)
client.set_credentials("GSSAPI", username, password, realm)

with client.connect() as conn:
    print(conn.whoami())

DBG: ldapconnection_new [self:000001BC571DB220]
DBG: ldapconnection_init (self:000001BC571DB220)
DBG: ldapconnection_open (self:000001BC571DB220)
DBG: connecting (self:000001BC571DB220)
DBG: create_conn_info (mech:GSSAPI, sock:-1, creds:000001BC56FD7E80)
DBG: ldapconnectiter_new [self:000001BC57077B20]
DBG: create_init_thread_data (client:000001BC56FDD130, sock:-1)
DBG: create_init_thread (ld:000001BC5695FC40, info:000001BC56994570, thread:0)
DBG: ldapconnection_result (self:000001BC571DB220, args:000001BC56FCEB40, kwds:0000000000000000)[msgid:-1]
DBG: LDAPConnection_Result (self:000001BC571DB220, msgid:-1, millisec:-1)
DBG: LDAPConnectIter_Next (self:000001BC57077B20, timeout:-1) [tls:0, state:0]
DBG: _ldap_finish_init_thread (async:0, thread:0000000000000DD8, timeout:-1, misc:000001BC5695FC40)
DBG: ldap_init_thread_func (params:000001BC5695FC40)
DBG: ldap_init_thread_func [retval:0]
DBG: binding [state:3]
DBG: _ldap_bind (ld:000001BC56926508, info:000001BC56994570, ppolicy:0, result:0000000000000000, msgid:0)
DBG: LDAPConnectIter_Next (self:000001BC57077B20, timeout:-1) [tls:0, state:4]
DBG: binding [state:4]
DBG: ldap_thread_bind (params:000001BC56994570)
DBG: ldapconnectiter_dealloc (self:000001BC57077B20)
DBG: dealloc_conn_info (info:000001BC56994570)
Traceback (most recent call last):
  File "<input>", line 19, in <module>
  File "C:\Users\jack\PycharmProjects\AD\venv\lib\site-packages\bonsai\ldapclient.py", line 588, in connect
    return LDAPConnection(self).open(timeout)
  File "C:\Users\jack\PycharmProjects\AD\venv\lib\site-packages\bonsai\ldapconnection.py", line 297, in open
    return super().open(timeout)
  File "C:\Users\jack\PycharmProjects\AD\venv\lib\site-packages\bonsai\ldapconnection.py", line 53, in open
    return self._evaluate(super().open(), timeout)
  File "C:\Users\jack\PycharmProjects\AD\venv\lib\site-packages\bonsai\ldapconnection.py", line 246, in _evaluate
    return self.get_result(msg_id, timeout)
bonsai.errors.AuthenticationError: Invalid Credentials. SSPI authentication procedure is failed with error code: 0x8009030c (0x0031 [49])

Never mind. You can install brew install krb5 for MIT Kerberos, then update the include and lib dirs in setup.cfg:
[build_ext]
include_dirs=/usr/local/opt/openldap/include:/usr/local/opt/krb5/include
library_dirs=/usr/local/opt/openldap/lib:/usr/local/opt/krb5/lib

But something still goes wrong on Mac, it fails to use the Kerberos ticket.

Yes so after recompiling I was able to get it to work on mac maybe I need to recompile it on windows as well. Interestingly the whoami() command shows this being run as the user I am logged in with and not the credentials that I passed.

@noirello Recompiling on windows didn't do anything I still get the same error.

The security implementation is completely different on Windows. No third party Kerberos library is involved, it uses libraries shipped with Windows by default.
Have you tried look into the security logs on the server side? It looks like that this article describes a similar issue.

Okay I will have to contact someome to see the logs on the server.
Is there any work around for the my token being used instead of generating a new token with the passed credentials?

I tried this on a linux machine(in AWS, AWS Linux), since the team that can help me look at the logs for windows is not available. I followed the guide. I installed the dependencies and build with the kerberos libraries.
I run into the following -
import bonsai
import configparser

bonsai.set_debug(True, -1)
bonsai.set_connect_async(False)

CACERT_FILE = "./Cert/cacerts.pem"

config = configparser.ConfigParser()
config.read('.//AD_Configs//Config.ini')
server_name = config['DOMAIN_1']['URL'] # 'ldaps://domain.com'
username = 'my_user'
password = 'SecretPassword#'
realm = config['Domain']['Domain']  # "domain.com"

client = bonsai.LDAPClient(server_name)
client.set_ca_cert(CACERT_FILE)
client.set_credentials("GSSAPI", username, password, realm)

with client.connect() as conn:
    print(conn.whoami())

ldap_url_parse_ext(ldap://localhost/)
ldap_init: trying /etc/openldap/ldap.conf
ldap_init: using /etc/openldap/ldap.conf
ldap_init: HOME env is /home/ec2-user
ldap_init: trying /home/ec2-user/ldaprc
ldap_init: trying /home/ec2-user/.ldaprc
ldap_init: LDAPCONF env is NULL
ldap_init: LDAPRC env is NULL
Is Bonsai build with kerberos -True
DBG: ldapconnection_new [self:0x7f4189ed2bb0]
DBG: ldapconnection_init (self:0x7f4189ed2bb0)
DBG: ldapconnection_open (self:0x7f4189ed2bb0)
DBG: connecting (self:0x7f4189ed2bb0)
DBG: create_conn_info (mech:GSSAPI, sock:-1, creds:0x7f4189ec1730)
DBG: ldapconnectiter_new [self:0x7f4189ec3ee0]
DBG: create_init_thread_data (client:0x7f4189ebf710, sock:-1)
DBG: create_init_thread (ld:0x1d810d0, info:0x1bf6d40, thread:0)
DBG: DBG: ldapconnection_result (self:0x7f4189ed2bb0, args:0x7f4189ec80a0, kwds:(nil))[msgid:-1]
DBG: LDAPConnection_Result (self:0x7f4189ed2bb0, msgid:-1, millisec:-1)
DBG: LDAPConnectIter_Next (self:0x7f4189ec3ee0, timeout:-1) [tls:0, state:0]
DBG: _ldap_finish_init_thread (async:0, thread:139919317710592, timeout:-1, misc:0x1d810d0)
DBG: _pthread_mutex_timedlock
ldap_init_thread_func (params:0x1d810d0)
ldap_create
ldap_url_parse_ext(ldaps://domain.com:636)
DBG: set connecting async: 0
DBG: create_krb5_cred (ctx:0x1c0a1e0, realm:domain.com, user:distinguished_name, password:****, ktname: , ccache:0x1bf6d78, gsscred:0x1bf6d80)
DBG: LDAPConnectIter_Next (self:0x7f4189ec3ee0, timeout:-1) [tls:0, state:0]
DBG: _ldap_finish_init_thread (async:0, thread:139919317710592, timeout:-1, misc:0x1d810d0)
DBG: _pthread_mutex_timedlock
DBG: LDAPConnectIter_Next (self:0x7f4189ec3ee0, timeout:-1) [tls:0, state:0]
DBG: _ldap_finish_init_thread (async:0, thread:139919317710592, timeout:-1, misc:0x1d810d0)
DBG: _pthread_mutex_timedlock
DBG: ldap_init_thread_func [retval:-1765328378]
DBG: ldapconnectiter_dealloc (self:0x7f4189ec3ee0)
DBG: dealloc_conn_info (info:0x1bf6d40)
DBG: remove_krb5_cred (ctx:0x1c0a1e0, cchache:0x7f4174009b20, gsscred:0x1bf6d80)
Traceback (most recent call last):
  File "/home/ec2-user/.pycharm_helpers/pydev/pydevd.py", line 1483, in _exec
    pydev_imports.execfile(file, globals, locals)  # execute the script
  File "/home/ec2-user/.pycharm_helpers/pydev/_pydev_imps/_pydev_execfile.py", line 18, in execfile
    exec(compile(contents+"\n", file, 'exec'), glob, loc)
  File "/home/ec2-user/AD_Audit_Automation/whoami.py", line 22, in <module>
    with client.connect() as conn:
  File "/usr/local/lib64/python3.7/site-packages/bonsai-1.2.1-py3.7-linux-x86_64.egg/bonsai/ldapclient.py", line 588, in connect
    return LDAPConnection(self).open(timeout)
  File "/usr/local/lib64/python3.7/site-packages/bonsai-1.2.1-py3.7-linux-x86_64.egg/bonsai/ldapconnection.py", line 297, in open
    return super().open(timeout)
  File "/usr/local/lib64/python3.7/site-packages/bonsai-1.2.1-py3.7-linux-x86_64.egg/bonsai/ldapconnection.py", line 53, in open
    return self._evaluate(super().open(), timeout)
  File "/usr/local/lib64/python3.7/site-packages/bonsai-1.2.1-py3.7-linux-x86_64.egg/bonsai/ldapconnection.py", line 246, in _evaluate
    return self.get_result(msg_id, timeout)
bonsai.errors.AuthenticationError: Client<EMAIL_ADDRESS>not found in Kerberos database. (KRB5_ERROR 0x96c73a06) (0x0031 [49])

The same works on my macbook after generating the ticket with kinit.
I noted the following -

When I change the name of the server config['DOMAIN_1']['URL'] from ldap://domain.com to ldap://specific_server.com and remove the username, password and realm the code works. I have to do both as I just remove the username, password and realm I get -
bonsai.errors.LDAPError: Local error. SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Server not found in Kerberos database) (0xFFFE [-2])
On my mac the distinguished_name of my user does not get<EMAIL_ADDRESS>but on linux in the error message I see it added ( I tested with the debugger and the username inside the conn variable does not have the<EMAIL_ADDRESS>

I looked into it a little:

On Mac: only kinit works currently, nothing else. Even when the Kerberos headers are available, the module can acquire a TGT, but during the LDAP authentication it uses the wrong (heimdal) ccache. I have no idea how to fix that. :(
On Linux: both kinit and module based TGT aquiring should work with a proper kdc.conf. Have you tried using a fully upper-cased domain name? Kerberos is sensitive to that. Might be the reason why the client wasn't found.

On mac - No problem. I logged into using the credentials I needed during the deevelopment.
On Linux - So I ran into the caps problem when I was trying to generate the ticket using Kinit from that point onwards I converted everything to the upper case. My krb5.conf looks okay -
includedir /etc/krb5.conf.d/

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = WINROOT.FMR.COM
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
forwardable = yes
rdns = false

Not sure where I can find the kdc.conf I looked into the directories mentioned in - https://manpages.ubuntu.com/manpages/bionic/man5/kdc.conf.5.html
couldn't find that in /etc/krb5kdc or in KRB5_KDC_PROFILE

On mac - No problem. I logged into using the credentials I needed during the deevelopment.
On Linux - So I ran into the caps problem when I was trying to generate the ticket using Kinit from that point onwards I converted everything to the upper case. My krb5.conf looks okay -
includedir /etc/krb5.conf.d/

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = DOMAIN.COM
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
forwardable = yes
rdns = false

Not sure where I can find the kdc.conf I looked into the directories mentioned in - https://manpages.ubuntu.com/manpages/bionic/man5/kdc.conf.5.html
couldn't find that in /etc/krb5kdc or in KRB5_KDC_PROFILE

Oh, sorry I meant krb5.conf, not kdc.conf (that's the server's configuration).
So using an upper-case realm for the LDAPClient.set_credentials's realm param did not help to avoid the authentication error on Linux?

It did not work. I get - bonsai.errors.LDAPError: Local error. SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Server not found in Kerberos database) (0xFFFE [-2]) error. Is there a reason why it does not resolve to the nearest domain server? Also If there are multiple referrals the script would break.


Adds lazy reader support for reading clobs

Adds LazyRawTextReader support for matching and reading clobs.
Fixes #634.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Sorry, I meant to approve this because none of my latest comments are things that would block the PR.

Thanks, I've got another PR out that depends on this one (#639), so I'll go ahead and merge this and address the comments as part of #635.


mock_auth['default'] is a hash instead of being an AuthHash ( https://github.com/intridea/omniauth/issues/558 )

I'm getting failing tests using
omniauth.info.email because omniauth is a hash. This is a patch to fix it.
Also its a response for this issue: https://github.com/intridea/omniauth/issues/558

Nice! I appreciate it! Will try it later and report back. :)


enhencement cancel inflight segcompaction tasks faster when load finish

[Goal]
When building the rowset writer, avoid waiting for inflight segcompaction to elimite long tail latency for load.
[Current situation]

The segcompaction of a rowset is executed serially. During the build phase, we need to wait for the completion of the inflight segcompaction task.

If the rowset writer finishes writing and starts building meta, then segments that have not been compacted will not be submitted to segcompaction worker. We simply ignore them to accelerate the build process.

But this is not enough. If a segcompaction task has already been submitted to the worker thread pool, we will set a cancelled flag for the worker, and nothing will be done during execution to complete the task ASAP.

But this is still not enough. Although the latency of the segcompaction task has been shortened by aforemetioned method, tasks may still be queuing in the thread pool.

[Solution]
We can increase the worker thread pool to avoid queuing congestion, but this is not the best solution.
Segcompaction should be a best effort work, and should not use too many CPU and memory resources. So we adopted the strategy of unbinding build and segcompaction, specifically:

For the segcompaction task that is performing compaction operations, we should not interrupt it, otherwise it may cause file corruption

For those tasks still queued, we no longer care about their results (because these tasks will know they are cancelled and will not perform any actual operations), so we just ignore them and continue with the subsequent rowset build process

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


Until all free hands are exhausted, "Handcuffed" alert will not show up and all hands remain usable

Description
Until all free hands are exhausted, "Handcuffed" alert will not show up and all hands will remain usable.
Reproduction

addhand self into four-armed mutant
Cuff self
Fail to notice difference beside cuffs sprite

Screenshots

This probably gets fixed by #9768, but that is currently waiting on UI refactor.