RecursionError: maximum recursion depth exceeded while calling a Python object

entire traceback
Traceback (most recent call last):
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/python_aternos/__init__.py", line 47, in from_credentials
    return cls.from_hashed(username, md5)
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/python_aternos/__init__.py", line 23, in from_hashed
    atconn.parse_token()
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/python_aternos/atconnect.py", line 23, in parse_token
    loginpage = self.request_cloudflare(
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/python_aternos/atconnect.py", line 142, in request_cloudflare
    self.request_cloudflare(
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/python_aternos/atconnect.py", line 142, in request_cloudflare
    self.request_cloudflare(
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/python_aternos/atconnect.py", line 142, in request_cloudflare
    self.request_cloudflare(
  [Previous line repeated 969 more times]
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/python_aternos/atconnect.py", line 134, in request_cloudflare
    req = self.session.get(
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/requests/sessions.py", line 555, in get
    return self.request('GET', url, **kwargs)
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/cloudscraper/__init__.py", line 257, in request
    self.perform_request(method, url, *args, **kwargs)
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/cloudscraper/__init__.py", line 190, in perform_request
    return super(CloudScraper, self).request(method, url, *args, **kwargs)
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/requests/sessions.py", line 542, in request
    resp = self.send(prep, **send_kwargs)
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/requests/sessions.py", line 655, in send
    r = adapter.send(request, **kwargs)
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/requests/adapters.py", line 439, in send
    resp = conn.urlopen(
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/urllib3/connectionpool.py", line 699, in urlopen
    httplib_response = self._make_request(
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/urllib3/connectionpool.py", line 445, in _make_request
    six.raise_from(e, None)
  File "<string>", line 3, in raise_from
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/urllib3/connectionpool.py", line 440, in _make_request
    httplib_response = conn.getresponse()
  File "/usr/lib/python3.8/http/client.py", line 1344, in getresponse
    response.begin()
  File "/usr/lib/python3.8/http/client.py", line 331, in begin
    self.headers = self.msg = parse_headers(self.fp)
  File "/usr/lib/python3.8/http/client.py", line 225, in parse_headers
    return email.parser.Parser(_class=_class).parsestr(hstring)
  File "/usr/lib/python3.8/email/parser.py", line 67, in parsestr
    return self.parse(StringIO(text), headersonly=headersonly)
  File "/usr/lib/python3.8/email/parser.py", line 56, in parse
    feedparser.feed(data)
  File "/usr/lib/python3.8/email/feedparser.py", line 176, in feed
    self._call_parse()
  File "/usr/lib/python3.8/email/feedparser.py", line 180, in _call_parse
    self._parse()
  File "/usr/lib/python3.8/email/feedparser.py", line 295, in _parsegen
    if self._cur.get_content_maintype() == 'message':
  File "/usr/lib/python3.8/email/message.py", line 594, in get_content_maintype
    ctype = self.get_content_type()
  File "/usr/lib/python3.8/email/message.py", line 578, in get_content_type
    value = self.get('content-type', missing)
  File "/usr/lib/python3.8/email/message.py", line 471, in get
    return self.policy.header_fetch_parse(k, v)
  File "/usr/lib/python3.8/email/_policybase.py", line 316, in header_fetch_parse
    return self._sanitize_header(name, value)
  File "/usr/lib/python3.8/email/_policybase.py", line 287, in _sanitize_header
    if _has_surrogates(value):
  File "/usr/lib/python3.8/email/utils.py", line 57, in _has_surrogates
    s.encode()

Here's the part of the code that logs in to aternos
from python_aternos import Client

intents = discord.Intents.all()
client = commands.Bot(command_prefix='>', intents=intents)
# Log in
try:
    atern = Client.from_credentials(f'{os.getenv("username")}', f'{os.getenv("password")}')
except Exception as a:
    print(a)
servs = atern.list_servers()

Hello. Thank you for opening the issue.
Your problem is the same as #17
python-aternos can't bypass the Cloudflare protection, and repeats the function call many times (view this code, it's a recursion).
I'm already working on it.

I've forgot to decrease the retries number...

Здравствуйте! Проблема будет решена на уровне API я верно понял?)

I hope / Надеюсь.

thanks for the quick reply
not facing recursion error anymore but the same one as zeyn now
Traceback (most recent call last):
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/python_aternos/atconnect.py", line 33, in parse_token
    token_func = js_code[1] if len(js_code) > 1 else js_code[0]
IndexError: list index out of range

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "main.py", line 13, in <module>
    atern = Client.from_credentials(f'{os.getenv("username")}', f'{os.getenv("password")}')
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/python_aternos/__init__.py", line 47, in from_credentials
    return cls.from_hashed(username, md5)
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/python_aternos/__init__.py", line 23, in from_hashed
    atconn.parse_token()
  File "/opt/virtualenvs/python3/lib/python3.8/site-packages/python_aternos/atconnect.py", line 39, in parse_token
    raise CredentialsError(
python_aternos.aterrors.CredentialsError: Unable to parse TOKEN from the page

@Sept1-c, are you still getting the CredentialsError?
Send me the token function:

Open a server panel (aternos.ort/server)
Open DevTools (Ctrl+Shift+I or Inspect in context menu)
Find the , click on the arrow to expand
Now, find the second

Please, update the module, I fixed it. JavaScript parser works properly now.

updated, still seem to get the same error
also couldn't find anything like the link you sent in any of the <script type=text/javascript>

Update it to 1.0.3.

Update it to 1.0.3.

This did nothing for me. Here is what is included in the

I think this issue can be closed, I fixed the RecursionError a long time ago.
Cloudflare protection bypassing can be discussed in #17 and #25


[TASK] upgrade dependency versions

Refer to this link for build results (access rights to CI server needed):
http://sdvjenkins.slub-dresden.de/job/Github PR GDM Model (Graph Json)/13/


Fix the rmw_connextdds_common build with gcc 13.2.

The most important fix here is to #include <cstdint>, but also make sure we #include for all used STL functions.

CI:

Linux
Linux-aarch64
Windows

The failures in CI jobs appeared in the latest nightlies https://github.com/osrf/buildfarm-tools/issues/31#issuecomment-1986832667 and appear unrelated. So I am merging this change to proceed with the release and build fix.


Adding City of Sydney

Thanks for doing this – but do you know why do Mascot, Eastlakes, Kensington, and Darling Point have such weird shapes…?
e.g.

My guess is that the weird shapes are the segments of those neighbourhoods
which are included in the City of Sydney's LGA boundary.
On Fri, Feb 27, 2015 at 1:49 PM, Marcin Wichary<EMAIL_ADDRESS>wrote:

Thanks for doing this – but do you know why do Mascot, Eastlakes,
Kensington, and Darling Point have such weird shapes…?
e.g.
[image: image]
https://cloud.githubusercontent.com/assets/2061609/6406629/251a9e4a-bde8-11e4-8bae-cd83c16ae9ff.png
—
Reply to this email directly or view it on GitHub
https://github.com/codeforamerica/click_that_hood/pull/264#issuecomment-76321836
.

Ah, right, hmm... @mwichary, to produce this we clipped a countrywide suburbs (neighborhoods) shapefile by the boundary for the city of Sydney, so the clipping process may have resulted in fragments (some suburbs/neighborhoods are partly in Sydney and partly outside it).

OK looking at it more in QGIS... it appears that Kensington has just a sliver of overlap with the City of Sydney (see the dark section on the borders in the image below). We should just remove that element from the geojson file.

Ah, and yes I checked the other suburbs mentioned. Same problem, as illustrated here (the only shapes with borders are the sliver polygons formed by the intersection of the suburbs and Sydney.

One last one...
I clipped the suburbs file by Sydney's boundary, then manually selected each polygon which was large enough to click. That gave me what appeared to be everything but then I took the inverse of that selection using the attribute table (resulting in a selection of suburbs too small to click -- sliver polygons). I saved those slivers as a new shapefile and modified the map so only those had a black border and all other layers were just fill.
You can see the sliver polygons as black lines, and I've then added in all suburbs and selected the ones that created those slivers.
The named suburbs should be all the ones that need to be removed from the dataset.

I don’t know if you meant to send an updated file, but I just removed the four offending neighbourhoods and pushed it live. http://click-that-hood.com/sydney
Please send any further changes if you see them. :·)
Thank you!!!

Awesome, thanks @mwichary!

Yeah awesome stuff! Thanks!
On Sun, Mar 1, 2015 at 10:17 PM, Peter W<EMAIL_ADDRESS>wrote:

Awesome, thanks @mwichary https://github.com/mwichary!
—
Reply to this email directly or view it on GitHub
https://github.com/codeforamerica/click_that_hood/pull/264#issuecomment-76592540
.


Sobolev-space orthogonal bases

This PR introduces an experimental transformation of L2-orthogonal bases to makes them jointly L2-orthogonal and Hk-orthogonal for Hk a sobolev space.

Jerry, I put something together very quickly without worrying too much about the most elegant way to achieve it. It will give us immediately an additional dimension to explore for the project with Veronika.


[BugFix] Can not find the correct repo when repo prefix is palo after fe restart (#18015)

What type of PR is this：

[x] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes ：

Fixes #18015
Problem Summary(Required) ：
Problem:
Now we use __starrocks prefix for repo, but if user have the __palo prefix repo, fe will get wrong prefix as __starrocks when fe restart.
Solution:
When Fe recover meta data for repo, it should try to list __palo prefix repo to check that if  __palo prefix repo is exist or not and reset prefix to the correct value. In this way, we can avoid to persist the prefix  value into the Image File.
Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto backported to target branch

[x] 2.5
[ ] 2.4
[ ] 2.3
[ ] 2.2

run starrocks_admit_test

[FE PR Coverage Check]
:heart_eyes: pass : 5 / 6 (83.33%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/backup/Repository.java
5
6
83.33%
[711]

@Mergifyio backport branch-2.5


Variable X is undefined and used without a fallback

When using the gulp script "npm run gulp watch-ie" I get following postcss-css-variables error:

The variables are from the TOC component and haven't been altered in any way.

Same here.
Happens even on a completely fresh download of the codyhouse-framework-master.zip when running the sass-ie task.

Hi 👋 It's an issue with the postcss-css-variables plugin: if the variables are not defined in the :root, it throws a warning. The variables are defined and work fine (e.g., the --gap-x variable is defined in the .grid class).

Hi Sebastiano. Thanks for the reply! The variables work as expected (and thus works 👌 in any modern browser), but whenever using the generated style-fallback.css, the styling seems to break. I'm in the (unfortunate) situation that I have to support IE11 so I'm experiencing code that turns out with "undefined" declarations. This is i.e. happening with the lists component. See below:

How would you suggest fixing this issue?

Hi! Moving the custom properties to the :root element should fix the issue:
:root {
  --list-space-y: var(--space-xxs); // vertical gaps
  --list-offset: var(--space-xs);  // sublist horizontal offset
  --list-line-height: var(--body-line-height);  // items line-height
}

I'll give it a test 👍

It's not really fixing it, unfortunately. The error is gone but the output is not satisfactory:

We just published a new version of the List component that fixes the IE issues:
https://codyhouse.co/ds/components/app/list

Perfect. Thanks a lot!


meshio.write error

I was trying to run example from pygmsh but find out error during meshio export, shown below
AttributeError: 'tuple' object has no attribute 'cells'
import pygmsh
import numpy as np
geom = pygmsh.built_in.Geometry()
poly = geom.add_polygon([
[ 0.0,  0.5, 0.0],
[-0.1,  0.1, 0.0],
[-0.5,  0.0, 0.0],
[-0.1, -0.1, 0.0],
[ 0.0, -0.5, 0.0],
[ 0.1, -0.1, 0.0],
[ 0.5,  0.0, 0.0],
[ 0.1,  0.1, 0.0]
],
lcar=0.05
)
axis = [0, 0, 1]
geom.extrude(
poly,
translation_axis=axis,
rotation_axis=axis,
point_on_axis=[0, 0, 0],
angle=2.0 / 6.0 * np.pi
)
mesh = pygmsh.generate_mesh(geom)
import meshio
meshio.write("test.vtk", mesh)
207
208     # check cells for sanity
--> 209     for key, value in mesh.cells.items():
210         if key[:7] == "polygon":
211             assert value.shape[1] == int(key[7:])
AttributeError: 'tuple' object has no attribute 'cells'

Looks like you are not using the latest version of meshio. Run pip install -U meshio to update meshio.

The version I used was not updated. Thanks.


The boot image can not be started by openstack qemu and kvm

download the image and decompress
zstd -d -T0 --long glaucus-s6-x86-64-v3-20240404.img.zst

What commands are you using to run the image?

Is this issue still relevant with the latest release?

Closing...


Implement + overload for string and list concat

Instead of writing list_concat(list_concat([1,2], [3]), [4]). We should support [1,2] + [3] + [4] for simplicity.

This query still causes a seg fault:
➜  shell git:(master) ✗ ./kuzu_shell dsad
Opened the database at path: dsad in read-write mode.
Enter ":help" for usage hints.
kuzu> return [[1,2]] + [[3]] + [[4]];
-------------------------------------------------------------------------------------------------
basic_string


Update README.md

Fixed broken link to Helix editor

I just realized it's actually helix-editor.com, not .org.


quick fixes for qc issues

[Current coverage][cc-pull] is 79.73%

Merging [#64][cc-pull] into [master][cc-base-branch] will decrease coverage by 0.01%

@@             master        #64   diff @@
==========================================
  Files            22         22
  Lines          2075       2073     -2
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits           1655       1653     -2
  Misses          420        420
  Partials          0          0

Powered by Codecov. Last updated by [d746dd0...5225abe][cc-compare]
[cc-base-branch]: https://codecov.io/gh/CyberReboot/vent/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/CyberReboot/vent/compare/d746dd0934f8ba69b07e160216512b1f071e4fa7...5225abe8e7d70e78f39e68c6faff4e796e1243f4?src=pr
[cc-pull]: https://codecov.io/gh/CyberReboot/vent/pull/64?src=pr


Feat/traceroute

Motivation
This pr implements a basic traceroute check.
Relates to #111, #112
Currently its using "github.com/aeden/traceroute" to implement the actual tracerouting logic, but I intend to to change this in the near future (more on this in #112).
In case you're testing this locally
The check is extremely slow, since it creates a lot of network requests. I tried to improve by concurrently running the check for every target, but the internals of the library do everything synchronously so there isn't much we can actually improve there outside of #112. While developing I used the below config, with retries set to 0, and it took a minute or so per run of the check.
Config
traceroute:
  interval: 5s
  timeout: 3s
  retries: 3
  maxHops: 8
  targets:
    - addr: <IP_ADDRESS>

Debugging
Since this check requires extra permissions to open the required sockets, debugging is a bit complicated. I have added a script in scripts/debug-elevated.sh which compiles sparrow as an unoptimized binary and launches it with a headless debugger and elevated permissions. You can then use the Connect to server target in the .vscode/launch.json to connect to the debugger and debug as usual. This is only necessary, when you actually need to debug the traceroute check, you can debug the others as usual.
Changes

For additional information look at the commits.
Tests done

TODO

[x] I've assigned this PR to myself
[x] I've labeled this PR correctly

@niklastreml Please also document the check in a new section of the README.


Time offset in forwarding history

Time can be specified as either epoch or using time expressions for start_time and end_time. If both are TE, then we can get a window relative to NOW by --start_time -2d --end_time -1d which is a one-day window starting two days ago. If start_time is epoch and end_time is TE then we can get a window of arbitrary length starting at the specified epoch; similar for end_time being epoch, we can get a window backwards. TE for start_time without end_time is interval ending at NOW and starting some number of h/d/w before.
EDIT: This is for issue: https://github.com/lightningnetwork/lnd/issues/1233

Superseeded by https://github.com/lightningnetwork/lnd/pull/1556


0x7fff5416b000 -     0x7fff5416cfff +libremovefile.dylib (49.102.1) <E3FE1B0B-ADEC-35C4-9977-97C4C93D922F> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/libremovefile.dylib
    0x7fff5416d000 -     0x7fff5416ffff +libsystem_featureflags.dylib (28.60.1) <CFA1634A-6D08-36E9-888C-A5E18553AA8A> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/libsystem_featureflags.dylib
    0x7fff54170000 -     0x7fff541b4fff +libsystem_m.dylib (3186.100.3) <0066159C-8A7D-3A1C-8177-39BEF8E416B5> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/libsystem_m.dylib
    0x7fff541b5000 -     0x7fff541bcfff +libunwind.dylib (201) <8E1CB200-3A8F-3BD7-A068-7BB9152B3946> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/libunwind.dylib
    0x7fff54441000 -     0x7fff544a8fff  com.apple.private.NanoRegistry (1.0 - 1) <228C56F9-8ED7-3946-BD93-DA1201C5B9C3> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/NanoRegistry.framework/NanoRegistry
    0x7fff544a9000 -     0x7fff544b7fff  com.apple.NanoPreferencesSync (1.0 - 1) <A1E5AC93-7A7E-3040-A6F6-B3E711EC9C04> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/NanoPreferencesSync.framework/NanoPreferencesSync
    0x7fff54cb6000 -     0x7fff54daffff  com.apple.audio.AVFAudio (1.0 - 477.84) <9168AC76-1EB0-3747-A70E-E3929C8A6927> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/AVFAudio.framework/AVFAudio
    0x7fff54e38000 -     0x7fff54e74fff  com.apple.CryptoTokenKit (1.0 - 1) <A3720416-8670-3346-8104-DA6EEA2E6403> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/CryptoTokenKit.framework/CryptoTokenKit
    0x7fff551a9000 -     0x7fff55e59fff +libLLVMContainer.dylib (6<IP_ADDRESS>) <FEC0BA62-5318-3DA6-B5F9-E06FD4BF4904> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/OpenGLES.framework/libLLVMContainer.dylib
    0x7fff56a67000 -     0x7fff56a78fff  com.apple.UniformTypeIdentifiers (636.8 - 636.8) <5F936733-80C6-34ED-947D-8014D277E7E4> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/UniformTypeIdentifiers.framework/UniformTypeIdentifiers
    0x7fff57ef7000 -     0x7fff57fb4fff  com.apple.AVFCapture (1.0 - <IP_ADDRESS>) <0B4F7D59-EFAD-342C-A6BC-780534744CB2> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/AVFCapture.framework/AVFCapture
    0x7fff57fb5000 -     0x7fff58112fff  com.apple.AVFCore (1.0 - 2010.31) <22DF813D-D621-36E1-9F1D-7642A1F1784E> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/AVFCore.framework/AVFCore
    0x7fff583f1000 -     0x7fff58406fff  com.apple.audio.AudioSession (1.0 - 76.69) <1F8D5F36-D4B8-3C35-8C3B-05E25B75D9E8> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/AudioSession.framework/AudioSession
    0x7fff58500000 -     0x7fff5853bfff  com.apple.CMCapture (1.0 - <IP_ADDRESS>) <1E3CA3E5-C68D-3C52-899A-D26AA7F34993> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/CMCapture.framework/CMCapture
    0x7fff5853c000 -     0x7fff58546fff  com.apple.CMCaptureCore (1.0 - <IP_ADDRESS>) <1078BBDE-E18A-33D3-9BBE-E4D76D602BAE> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/CMCaptureCore.framework/CMCaptureCore
    0x7fff5855e000 -     0x7fff585dafff  com.apple.CVNLP (1.0 - 119) <DCD98F86-F47D-3331-8E32-974DE3287B3D> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/CVNLP.framework/CVNLP
    0x7fff58896000 -     0x7fff5889efff  com.apple.contextkit.ContextKitExtraction (1.0 - 1) <89240C99-F465-3DA8-9AC9-13678EA148CF> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/ContextKitExtraction.framework/ContextKitExtraction
    0x7fff588ea000 -     0x7fff58928fff  com.apple.CoreAutoLayout (1.0 - 20) <B29346A0-AEDA-347B-B707-08FCAE600F76> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/CoreAutoLayout.framework/CoreAutoLayout
    0x7fff58dc5000 -     0x7fff58dcbfff  com.apple.ExtensionFoundation (19.6 - 19.6) <AD8D8210-D245-3E7A-86FE-CA4F5D1C0786> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/ExtensionFoundation.framework/ExtensionFoundation
    0x7fff58dcc000 -     0x7fff58de3fff  com.apple.ExtensionKit (19.6 - 19.6) <6B405BBF-B30B-3C44-82E2-3B8D48869F1E> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/ExtensionKit.framework/ExtensionKit
    0x7fff5903f000 -     0x7fff59165fff  com.apple.InternalSwiftProtobuf (1.0 - 1.14.0) <727FC2CC-7BEA-30AB-8B75-C3312C2F4EA1> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/InternalSwiftProtobuf.framework/InternalSwiftProtobuf
    0x7fff5951e000 -     0x7fff59c2cfff  com.apple.PegasusAPI (1.0 - 386.4.41) <3CA5B568-81CE-3AFB-B054-C8271024CFE2> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/PegasusAPI.framework/PegasusAPI
    0x7fff59c66000 -     0x7fff59c70fff  com.apple.PointerUIServices (1.0 - 1) <98F2CCA2-FD9A-378B-A824-7D9DF69E803A> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/PointerUIServices.framework/PointerUIServices
    0x7fff59c97000 -     0x7fff59cb1fff  com.apple.proactive.ProactiveInputPredictions (1.0 - 1115.515) <82419EB2-3B94-3580-AF40-BCD78E157FEA> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/ProactiveInputPredictions.framework/ProactiveInputPredictions
    0x7fff5b3de000 -     0x7fff5b3ecfff  com.apple.CoreSimulator.SimFramebufferClient (732.8 - 732.8) <66DCC2D9-FB0C-30C4-AE7F-44C410820EC2> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/SimFramebufferClient.framework/SimFramebufferClient
    0x7fff5b3ed000 -     0x7fff5b3f0fff  com.apple.iphonesimulator.SimulatorClient (1.0 - 1) <784AA27D-9B80-304C-AAA6-5EAA8EE95EF0> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/SimulatorClient.framework/SimulatorClient
    0x7fff5c5e3000 -     0x7fff5c5e3fff  com.apple.SoftLinking (1.0 - 1) <EEF049E8-87B6-3958-9D85-B18874EBA961> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/SoftLinking.framework/SoftLinking
    0x7fff5c664000 -     0x7fff5c671fff  com.apple.metadata.SpotlightLinguistics (1.0 - 1) <707A84E7-B197-3BD2-9B88-93629979BA10> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/SpotlightLinguistics.framework/SpotlightLinguistics
    0x7fff601c5000 -     0x7fff601ddfff +libexpat.1.dylib (26) <63617455-BFB4-3D22-9350-9B101FF19E78> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libexpat.1.dylib
    0x7fff602ff000 -     0x7fff60301fff +libsystem_collections.dylib (1439.100.3) <12BCF738-F776-3DE1-9583-4F7A1A24AFD9> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/libsystem_collections.dylib
    0x7fff60302000 -     0x7fff60331fff +libsystem_kernel.dylib (7195.141.2) <B51DEA59-1260-35C6-B7B6-AA6D8459ECEC> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/libsystem_kernel.dylib
    0x7fff60332000 -     0x7fff6033bfff +libsystem_platform.dylib (254.80.2) <6F368391-D41B-3A7E-9992-6000FA985F21> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/libsystem_platform.dylib
    0x7fff6033c000 -     0x7fff6033cfff +libsystem_product_info_filter.dylib (8.40.1) <0CEDFB37-B468-335A-9DBC-BB158E2D2CC2> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/libsystem_product_info_filter.dylib
    0x7fff6033d000 -     0x7fff60348fff +libsystem_pthread.dylib (454.120.2) <B1A74420-49E9-32FC-BFCB-E53550236A23> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/libsystem_pthread.dylib
    0x7fff60349000 -     0x7fff6034afff +libsystem_sim_kernel.dylib (227.100.2) <578CEA54-D770-375B-950B-2D35EF7E6CE8> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/libsystem_sim_kernel.dylib
    0x7fff6034b000 -     0x7fff6034bfff +libsystem_sim_kernel_host.dylib (227.100.2) <348EE060-5BBD-3E64-B9D5-02485537D257> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/libsystem_sim_kernel_host.dylib
    0x7fff6034c000 -     0x7fff6034efff +libsystem_sim_platform.dylib (227.100.2) <2B4DFA3F-E350-3A4E-8199-85A35C642C5D> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/libsystem_sim_platform.dylib
    0x7fff6034f000 -     0x7fff6034ffff +libsystem_sim_platform_host.dylib (227.100.2) <CBA21F2A-FC4D-39CB-B8AA-C90FCF399B59> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/libsystem_sim_platform_host.dylib
    0x7fff60350000 -     0x7fff60350fff +libsystem_sim_pthread.dylib (227.100.2) <AA2DDD04-01FE-3884-A992-6A268849C0E8> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/libsystem_sim_pthread.dylib
    0x7fff60351000 -     0x7fff60351fff +libsystem_sim_pthread_host.dylib (227.100.2) <40764C89-3271-3DC1-BC4B-1F3D2FCEC6F6> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/libsystem_sim_pthread_host.dylib

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 67
    thread_create: 0
    thread_set_state: 1267

VM Region Summary:
ReadOnly portion of Libraries: Total=679.0M resident=0K(0%) swapped_out_or_unallocated=679.0M(100%)
Writable regions: Total=2.2G written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=2.2G(100%)

                                VIRTUAL   REGION
REGION TYPE                        SIZE    COUNT (non-coalesced)
===========                     =======  =======
Activity Tracing                   256K        1
CoreData Object IDs               4100K        2
Dispatch continuations            16.0M        1
Foundation                          16K        1
Kernel Alloc Once                    8K        1
MALLOC                           278.3M       65
MALLOC guard page                   48K       10
MALLOC_MEDIUM (reserved)           1.9G       16         reserved VM address space (unallocated)
SQLite page cache                  704K       11
STACK GUARD                       56.0M       11
Stack                             13.1M       11
VM_ALLOCATE                        208K        3
__DATA                            11.1M      370
__DATA_CONST                      26.8M      366
__DATA_DIRTY                        22K       10
__FONT_DATA                          4K        1
__LINKEDIT                       421.8M        7
__OBJC_RO                         62.5M        1
__OBJC_RW                         2656K        1
__TEXT                           257.2M      375
__UNICODE                          588K        1
mapped file                       93.0M       45
shared memory                       16K        1
===========                     =======  =======
TOTAL                              3.1G     1311
TOTAL, minus reserved VM space     1.2G     1311

System logs from iOS always says this
error	10:46:37.923445-0700	kbd	Unable to send message for autohidePointerForReason: with isConnectionActive: NO

You should also file a radar bug with Apple too.  It should be a guarantee of the operating system that a user process can't take down the whole keyboard.

Good idea, I will file that.
In meantime can Flutter team help us in some way to mitigate this or provide us some tips ?

Yep, I'm not just passing the buck to Apple, but we still need some repro code.  That's our best way forward.

Thanks @gaaclarke I am looking into the repro code now.
Also just to add to the repro steps it seems
If we remove our custom TextEditController freezing doesnt happen.
So something around the our usage of editcontroller with the keyboard gets us in this weird state.

Hi @gaaclarke
Here is a trimmed down version of the repro steps. While it may take some time to get the keyboard crashing, but one thing is sure it does crash, with the above iOS crash logs attached in my previous comment.
The easiest way to repro is to

Add bunch of text in the description, title and the main content section.
Especially in the content section use the - icon to add new lines and try switching between emoji and text keyboard to type.
At any instant, you will eventually find the keyboard unresponsive, and you would need to reboot the device to get it working back.

This is the crashed state screen: The app is responsive, but keyboard doesn't work anymore.

Here is the repo for the repro code:
https://github.com/ThatchTravel/keyboard_crash

Thanks.  I ran that code and immediately start getting Stack Overflow exceptions:

StackOverflowError
══╡ EXCEPTION CAUGHT BY SERVICES LIBRARY ╞══════════════════════════════════════════════════════════
The following StackOverflowError was thrown during a platform message callback:
Stack Overflow

When the exception was thrown, this was the stack:
#0      Duration.inMicroseconds (dart:core/duration.dart:226:3)
#1      Duration.toString (dart:core/duration.dart:274:9)
#2      _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#3      Duration.toString (dart:core/duration.dart:275:25)
#4      _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#5      Duration.toString (dart:core/duration.dart:275:25)
#6      _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#7      Duration.toString (dart:core/duration.dart:275:25)
#8      _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#9      Duration.toString (dart:core/duration.dart:275:25)
#10     _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#11     Duration.toString (dart:core/duration.dart:275:25)
#12     _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#13     Duration.toString (dart:core/duration.dart:275:25)
#14     _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#15     Duration.toString (dart:core/duration.dart:275:25)
#16     _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#17     Duration.toString (dart:core/duration.dart:275:25)
#18     _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#19     Duration.toString (dart:core/duration.dart:275:25)
#20     _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#21     Duration.toString (dart:core/duration.dart:275:25)
#22     _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#23     Duration.toString (dart:core/duration.dart:275:25)
#24     _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#25     Duration.toString (dart:core/duration.dart:275:25)
#26     _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#27     Duration.toString (dart:core/duration.dart:275:25)
#28     _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#29     Duration.toString (dart:core/duration.dart:275:25)
#30     _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#31     Duration.toString (dart:core/duration.dart:275:25)
#32     _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#33     Duration.toString (dart:core/duration.dart:275:25)
#34     _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#35     Duration.toString (dart:core/duration.dart:275:25)
#36     _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#37     Duration.toString (dart:core/duration.dart:275:25)
#38     _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#39     Duration.toString (dart:core/duration.dart:275:25)
#40     _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#41     Duration.toString (dart:core/duration.dart:275:25)
#42     _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#43     Duration.toString (dart:core/duration.dart:275:25)
...
...
#3790   _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#3791   Duration.toString (dart:core/duration.dart:275:25)
#3792   _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#3793   Duration.toString (dart:core/duration.dart:275:25)
#3794   DiagnosticsProperty.valueToString (package:flutter/src/foundation/diagnostics.dart:2741:60)
#3795   DiagnosticsProperty.toDescription (package:flutter/src/foundation/diagnostics.dart:2755:21)
#3796   TextTreeRenderer._debugRender (package:flutter/src/foundation/diagnostics.dart:1194:32)
#3797   TextTreeRenderer.render (package:flutter/src/foundation/diagnostics.dart:1126:14)
#3798   TextTreeRenderer._debugRender (package:flutter/src/foundation/diagnostics.dart:1304:39)
#3799   TextTreeRenderer.render (package:flutter/src/foundation/diagnostics.dart:1126:14)
#3800   DiagnosticsNode.toStringDeep.<anonymous closure> (package:flutter/src/foundation/diagnostics.dart:1744:9)
#3801   DiagnosticsNode.toStringDeep (package:flutter/src/foundation/diagnostics.dart:1751:6)
#3802   DiagnosticsNode.toString.<anonymous closure> (package:flutter/src/foundation/diagnostics.dart:1661:18)
#3803   DiagnosticsNode.toString (package:flutter/src/foundation/diagnostics.dart:1673:6)
#3804   Diagnosticable.toString.<anonymous closure> (package:flutter/src/foundation/diagnostics.dart:3111:78)
#3805   Diagnosticable.toString (package:flutter/src/foundation/diagnostics.dart:3113:6)
#3806   StringBuffer.write (dart:core-patch/string_buffer_patch.dart:64:22)
#3807   StringBuffer.writeAll (dart:core-patch/string_buffer_patch.dart:102:7)
#3808   IterableBase.iterableToFullString (dart:collection/iterable.dart:268:14)
#3809   ListBase.listToString (dart:collection/list.dart:43:20)
#3810   List.toString (dart:core-patch/growable_array.dart:489:33)
#3811   _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#3812   KeyMessage.toString (package:flutter/src/services/hardware_keyboard.dart:683:33)
#3813   _StringBase._interpolate (dart:core-patch/string_patch.dart:846:19)
#3814   FocusManager._handleKeyMessage (package:flutter/src/widgets/focus_manager.dart:1575:53)
#3815   KeyEventManager.handleRawKeyMessage (package:flutter/src/services/hardware_keyboard.dart:830:35)
#3816   BasicMessageChannel.setMessageHandler.<anonymous closure> (package:flutter/src/services/platform_channel.dart:73:49)
#3817   BasicMessageChannel.setMessageHandler.<anonymous closure> (package:flutter/src/services/platform_channel.dart:72:47)
#3818   _DefaultBinaryMessenger.setMessageHandler.<anonymous closure> (package:flutter/src/services/binding.dart:379:35)
#3819   _DefaultBinaryMessenger.setMessageHandler.<anonymous closure> (package:flutter/src/services/binding.dart:376:46)
#3820   _invoke2.<anonymous closure> (dart:ui/hooks.dart:205:15)
#3824   _invoke2 (dart:ui/hooks.dart:204:10)
#3825   _ChannelCallbackRecord.invoke (dart:ui/channel_buffers.dart:42:5)
#3826   _Channel.push (dart:ui/channel_buffers.dart:132:31)
#3827   ChannelBuffers.push (dart:ui/channel_buffers.dart:329:17)
#3828   PlatformDispatcher._dispatchPlatformMessage (dart:ui/platform_dispatcher.dart:544:22)
#3829   _dispatchPlatformMessage (dart:ui/hooks.dart:92:31)
(elided 3 frames from dart:async)
════════════════════════════════════════════════════════════════════════════════════════════════════

The keyboard was never responsive, every keystroke was painful.  Here is another error that was printed out a few times:
[VERBOSE-2:ui_dart_state.cc(209)] Unhandled Exception: 'package:flutter/src/services/hardware_keyboard.dart': Failed assertion: line 790 pos 16: '(data.physical == 0 && data.logical == 0) ||
               (data.physical != 0 && data.logical != 0)': is not true.
#0      _AssertionError._doThrowNew (dart:core-patch/errors_patch.dart:46:39)
#1      _AssertionError._throwNew (dart:core-patch/errors_patch.dart:36:5)
#2      KeyEventManager.handleKeyData (package:flutter/src/services/hardware_keyboard.dart:790:16)
#3      PlatformDispatcher._dispatchKeyData.<anonymous closure> (dart:ui/platform_dispatcher.dart:375:61)
#4      _invoke2.<anonymous closure> (dart:ui/hooks.dart:205:15)
#5      _rootRun (dart:async/zone.dart:1428:13)
#6      _CustomZone.run (dart:async/zone.dart:1328:19)
#7      _CustomZone.runGuarded (dart:async/zone.dart:1236:7)
#8      _invoke2 (dart:ui/hooks.dart:204:10)
#9      PlatformDispatcher._dispatchKeyData (dart:ui/platform_dispatcher.dart:373:5)
#10     _dispatchKeyData (dart:ui/h<…>

I was running on Flutter (Channel master, 2.6.0-6.0.pre.11, on macOS 11.6 20G165 darwin-x64, locale en-US) on an iOS 14.5 simulator.
When launching from Xcode I didn't see these errors but I saw a different one:
2021-09-22 09:46:26.220888-0700 Runner[82211:1790233] [Assert] Unexpected touch phase during forwarding
I read through the code a bit and probably someone that knows the Framework might be able to debug this.  My recommendation would be to go through the exercise of making this the minimal code needed to reproduce the issue.  The reason is that:

During the process of trimming down, you might discover what's leading to the issue.  For example: is the flutter_keyboard_visibility plugin necessary for reproduction of the bug?  If not it shouldn't be in the minimal reproduction code.
The developers have a lot of issues they are working through, the more difficult to grasp your issue is, the less likely it will get prioritized.
The more simple the reproduction the more likely someone running into the same issue will find it.

FWIW I almost think you are somehow running into some unintended recursion, possibly listeners of events causing edits that trigger listeners, something like that.

Thanks @gaaclarke for the pointers, we will see if we can trim this down any further, but we felt these are important aspects of the app, so we added them in the repro steps.
Also specifically for the error you mentioned above, there is a different bug filed for it, as a workaround you can try toggling hardware keyboard option on simulator to get the soft keyboard up.
More here: https://github.com/flutter/flutter/issues/90068
Will try to see what else we can do, but kbd process on iOS crashes with these steps.

@gaaclarke The stack overflow looks unrelated to our code as it is a callback from the hardware keyboard? I am not sure how we could influence a stack overflow in the Duration class from there?
The code in Duration.toString is recursive if it is in the past:
    if (inMicroseconds < 0) {
      return "-${-this}";
    }

HI @gaaclarke we have trimmed down the repro app further. Please let us know if its helpful.

Thanks, that's more clear.  I played around with this a bit.  Here's what I saw:

I didn't see the error on Android (which means it's very unlikely to be a framework / user error).
I was able to reproduce the issue once and when I did I paused the debugger and saw that no flutter code was running on any of the threads (this means there isn't some sort of deadlock or infinite loop happening in the engine).  I reproduced it with just typing text and newlines, no keyboard shifts.
There was no error or exception printed on the console when I reproduced the issue.
After restarting the simulator I couldn't get it to happen again
The app is really unresponsive when using the hardware keyboard, but performs fine with the software keyboard on the simulator (I'm not sure if this is relevant at all but tripped me up).

I don't think there is a lot of evidence here that points to a bug in Flutter unfortunately.  We know it's not in the framework, we don't see the embedder misbehaving in terms of errors or the code that is executing once we get to the freezing state.
Have you tried testing on a few different versions of iOS?  Do you have more concrete reproduction steps?  My recommendation for steps forward:

Continue to try to work with Apple on a bug report
Test on a few versions of iOS
Try to see if you can create deterministic reproduction steps
Try to develop evidence that the bug is in Flutter and not a platform bug

Thanks @gaaclarke.
I also noticed some unrelated issues with hardware keyboard when cutting down the sample. Specifically on Linux desktop the hardware keyboard crashes and becomes unresponsive after a hot restart which seems to be a regression in Flutter 2.5.x and is unrelated to the core issue we are seeing, but is also something affecting our app on iPad with a keyboard. We have not seen this particular crash on any other platform.
Does the Flutter team work with Apple on platform bugs? It sounds like this is a corner case that would be affecting other Flutter applications as well?
Is there anything we are doing different in these text fields that stands out to you? We don't see the crash in the text fields in the header section, only the dynamic editor section.
One other data point: we have had reports of the users device heating up before the issue occurs.

I'm not a good person to ask about Flutter framework usage.  I work mostly under the covers in the engine.  I didn't try to reproduce this on device, but you've stated it happens on devices too, right?  The crash in kbd you posted is for the simulator.
@goderbauer this team is getting weird behaviors on iOS with TextEditingController.  I've reproduced it locally once and I can't conclusively tie it to anything Flutter is doing wrong (framework or engine) and it seems to be an apple bug since it is taking down the whole operating system.  I've worked with them to trim it down to small(ish) reproduction code.  Can someone on the framework team give it a quick glance to see if they are doing something obviously oddball that would lead them to see this behavior?

Filed this apple bug with full crash logs and other repro scenarios which we have seen:
https://developer.apple.com/forums/thread/690698#690698021

@gaaclarke we were initially seeing this on device, but once we found it was reproducible on the simulator it was a quicker testing cycle since a restart is necessary to get the keyboard back.

@gaaclarke we have cut down the sample app even further and still see crashes

Crash Report

Hardware Model:      iPhone13,4
Process:             kbd [402]
Path:                /System/Library/TextInput/kbd
Identifier:          kbd
Version:             ???
Code Type:           ARM-64 (Native)
Role:                Foreground
Parent Process:      launchd [1]
Coalition:           com.apple.TextInput.kbd [595]

Date/Time:           2021-09-23 22:05:24.4993 -0500
Launch Time:         2021-09-23 16:15:13.0077 -0500
OS Version:          iPhone OS 15.0 (19A346)
Release Type:        User
Baseband Version:    2.09.10
Report Version:      104

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x000000026b7420f7
Exception Codes: 0x0000000000000001, 0x000000026b7420f7
VM Region Info: 0x26b7420f7 is not in any region.  Bytes after previous region:<PHONE_NUMBER>  Bytes before following region:<PHONE_NUMBER>3
      REGION TYPE                 START - END      [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      unused shlib __TEXT      2150c9000-215bb8000 [ 10.9M] r--/r-- SM=COW  ... this process
--->  GAP OF 0xdaa448000 BYTES
      VM_ALLOCATE              fc0000000-1000000000 [  1.0G] ---/--- SM=COW
Exception Note:  EXC_CORPSE_NOTIFY
Termination Reason: SIGNAL; [11]
Terminating Process: exc handler [402]

Terminating Process: exc handler [402]
Triggered by Thread:  0

Thread 0 name:   Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   TextInputCore                 	       0x1af6b04e4 KB::String::iterator::operator--+ 62692 () + 132
1   TextInputCore                 	       0x1af6b0478 KB::String::iterator::operator--+ 62584 () + 24
2   TextInputCore                 	       0x1af78af5c KB::String::find_last_of+ 958300 (KB::String const&, KB::String::iterator const&) const + 176
3   TextInputCore                 	       0x1af750664 KB::String::find_last_of+ 718436 (KB::String const&) const + 96
4   TextInputCore                 	       0x1af74e8f0 TIInputManager::should_generate_candidates+ 710896 (KB::String const&, KB::String const&) const + 432
5   TextInputCore                 	       0x1af7ba818 -[TIKeyboardInputManager canTrimInputAtIndex:] + 220
6   TextInputCore                 	       0x1af7ba528 -[TIKeyboardInputManager trimInput] + 224
7   TextInputCore                 	       0x1af7c3e68 -[TIKeyboardInputManager addInput:withContext:] + 1852
8   TextInputCore                 	       0x1af7c43b4 -[TIKeyboardInputManager handleKeyboardInput:] + 896
9   TextInputCore                 	       0x1af70595c -[TIKeyboardInputManagerWrapper handleKeyboardInput:acceptedSecureCandidate:keyboardState:completionHandler:] + 1444
10  TextInputCore                 	       0x1af705dc0 -[TIKeyboardInputManagerWrapper handleKeyboardInput:keyboardState:completionHandler:] + 392
11  TextInputCore                 	       0x1af721324 -[TIKeyboardInputManagerPolymorph handleKeyboardInput:keyboardState:completionHandler:] + 860
12  Foundation                    	       0x184b4e6b0 __NSXPCCONNECTION_IS_CALLING_OUT_TO_EXPORTED_OBJECT_S3__ + 16
13  Foundation                    	       0x184b0429c -[NSXPCConnection _decodeAndInvokeMessageWithEvent:flags:] + 1828
14  Foundation                    	       0x184af4764 message_handler + 228
15  libxpc.dylib                  	       0x1f37a34e0 _xpc_connection_call_event_handler + 176
16  libxpc.dylib                  	       0x1f37a3904 _xpc_connection_mach_event + 980
17  libdispatch.dylib             	       0x182fb6a10 _dispatch_client_callout4 + 20
18  libdispatch.dylib             	       0x182fd28a4 _dispatch_mach_msg_invoke + 476
19  libdispatch.dylib             	       0x182fbdf84 _dispatch_lane_serial_drain + 368
20  libdispatch.dylib             	       0x182fd35f4 _dispatch_mach_invoke + 456
21  libdispatch.dylib             	       0x182fc4c84 _dispatch_main_queue_callback_4CF + 768
22  CoreFoundation                	       0x1832fcce4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16
23  CoreFoundation                	       0x1832b6ebc __CFRunLoopRun + 2540
24  CoreFoundation                	       0x1832ca3c8 CFRunLoopRunSpecific + 600
25  Foundation                    	       0x184aedd54 -[NSRunLoop+ 101716 (NSRunLoop) runMode:beforeDate:] + 236
26  Foundation                    	       0x184aee510 -[NSRunLoop+ 103696 (NSRunLoop) run] + 92
27  kbd                           	       0x1046c17dc 0x1046bc000 + 22492
28  dyld                          	       0x104955a24 start + 520

Thread 1:
0   libsystem_pthread.dylib       	       0x1f3778f48 start_wqthread + 0

Thread 2:
0   libsystem_pthread.dylib       	       0x1f3778f48 start_wqthread + 0

Thread 3:
0   libsystem_pthread.dylib       	       0x1f3778f48 start_wqthread + 0

Thread 4:
0   libsystem_pthread.dylib       	       0x1f3778f48 start_wqthread + 0

Thread 5:
0   libsystem_pthread.dylib       	       0x1f3778f48 start_wqthread + 0

Thread 6:
0   libsystem_pthread.dylib       	       0x1f3778f48 start_wqthread + 0

Thread 0 crashed with ARM Thread State (64-bit):
    x0: 0x0000000000000003   x1: 0x0000000000000000   x2: 0x000000016b742008   x3: 0x000000016b742102
    x4: 0x0000000000000008   x5: 0x0000000000000001   x6: 0x0000000000000069   x7: 0x0000000000000000
    x8: 0x000000000000003c   x9: 0x0000000000000000  x10: 0x000000016b7420f8  x11: 0x0000000000000012
   x12: 0x0000000000000003  x13: 0x00000000ffffffff  x14: 0x0000000000000000  x15: 0x00000000fffffffd
   x16: 0xb5081181f3770a50  x17: 0x00000001e0a67768  x18: 0x0000000000000000  x19: 0x000000016b741f50
   x20: 0x000000016b7420e8  x21: 0x000000016b7420c8  x22: 0x000000016b741f90  x23: 0x000000016b7420f8
   x24: 0x0000000000000001  x25: 0x0000000000000004  x26: 0x000000011fd56110  x27: 0x00000001cd8a5499
   x28: 0x000000011fd670a0   fp: 0x000000016b741f40   lr: 0x00000001af6b0478
    sp: 0x000000016b741f30   pc: 0x00000001af6b04e4 cpsr: 0x80000000
   far: 0x000000026b7420f7  esr: 0x92000006 (Data Abort) byte read Translation fault

Binary Images:
       0x1af6a1000 -        0x1af8cffff TextInputCore arm64e  <ee65789fa44234028448b4253567635e> /System/Library/PrivateFrameworks/TextInputCore.framework/TextInputCore
       0x184ad5000 -        0x184dd9fff Foundation arm64e  <efbca2ff8b8c3227abbc154ba851d23c> /System/Library/Frameworks/Foundation.framework/Foundation
       0x1f3793000 -        0x1f37cafff libxpc.dylib arm64e  <e8a600510c6835aeaefd9d97cc7f2696> /usr/lib/system/libxpc.dylib
       0x182fb3000 -        0x182ff8fff libdispatch.dylib arm64e  <959cd6e40ce73022b73c8b36f79f4745> /usr/lib/system/libdispatch.dylib
       0x1832ab000 -        0x1836fefff CoreFoundation arm64e  <6174789ae88c3f5cba39de2e9edc0750> /System/Library/Frameworks/CoreFoundation.framework/CoreFoundation
       0x1046bc000 -        0x1046cffff kbd arm64e  <8918b46b7bdd3c16be5447f6e0e5e167> /System/Library/TextInput/kbd
       0x10493c000 -        0x104993fff dyld arm64e  <d48c31ee061f370ba6f78391a1b53ed8> /usr/lib/dyld
       0x1f3778000 -        0x1f3783fff libsystem_pthread.dylib arm64e  <bc1ce0c6a9f2396b9afb623d3acd5881> /usr/lib/system/libsystem_pthread.dylib
               0x0 - 0xffffffffffffffff ??? unknown-arch  <00000000000000000000000000000000> ???

@safarmer does this issue reproduce in profile and release mode as well or does it only reproduce during debug mode?

In our production application, it is happening in release mode. With the repro app, we have been verifying in debug mode. I am running a profile build now on device and have not crashed yet. I have not crashed the repro app this time around, but I am much less consistent reproducing than others on the team that are currently offline.
@ahetawal-p @amwest0 have you been able to crash the repro app in profile or release build mode?

@danagbemava-nc we have had reports of warm/hot devices when it happens. Since I am testing on a development phone that isn't doing a whole lot other than running the app, I may not be stressing the device as much as others on my team that are testing on their personal iPhones.

@danagbemava-nc it just crashed on a profile build on an iPhone XS. I ran a benchmark to warm things up a little and it completely locked up when I entered keyboard navigation mode (holding my finger down on the keyboard).

Did you notice anything strange in the devtools while you were running in profile mode?
I'm attempting to reproduce on my end as well.

There was this in the console. This looks like yet another crash and is different to the initial issue.
*** Assertion failure in -[FlutterTextInputView beginFloatingCursorAtPoint:], FlutterTextInputPlugin.mm:1297
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Another floating cursor is currently active.'
*** First throw call stack:
(0x182f7305c 0x19b48df54 0x18483499c 0x101ecd80c 0x18616404c 0x18592a4bc 0x1857d51cc 0x186163e58 0x1861694e0 0x185564584 0x18552d1d0 0x185efe204 0x185613938 0x185f15d1c 0x185536080 0x1854064b0 0x18556132c 0x1847d3048 0x18475c874 0x1847ee134 0x184748810 0x184756bec 0x185583c3c 0x186c3c20c 0x186c42b60 0x182ee53a0 0x182f28734 0x182f2bf40 0x182ee5e1c 0x182ef93c8 0x19e70a38c 0x18589f0bc 0x18561cbe8 0x100805f7c 0x100bc1a24)
libc++abi: terminating with uncaught exception of type NSException
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x00000001b98619c4 libsystem_kernel.dylib`__pthread_kill + 8
libsystem_kernel.dylib`__pthread_kill:
->  0x1b98619c4 <+8>:  b.lo   0x1b98619e4               ; <+40>
    0x1b98619c8 <+12>: pacibsp
    0x1b98619cc <+16>: stp    x29, x30, [sp, #-0x10]!
    0x1b98619d0 <+20>: mov    x29, sp
Target 0: (Runner) stopped.

These are some recent crash logs from the device around the time of the crash:
backboardd 24-9-21, 4-40 pm.crash.log
ios  24-9-21, 4-44 pm.crash.log
kbd  24-9-21, 4-50 pm.crash.log

The error message from https://github.com/flutter/flutter/issues/90238#issuecomment-926390606 is similar to another issue being tracked here. Reproduction steps are also quite similar to steps in https://github.com/flutter/flutter/issues/90238#issuecomment-926387333
At this point I believe it is wise for it to be labelled so we can get more insight from the other teams.
Labelling as passed for now since I haven't been able to reproduce it locally.

Thanks @danagbemava-nc. Hopefully the rest of my team are able to give some more info/steps in their morning.

Just confirming, it looks like https://github.com/ThatchTravel/keyboard_crash is our smallest reduction so far?
The crashes in question look like kbd (keyboard deamon I assume?) is crashing in TextInputCore on a bad pointer:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x000000026f4ea2a7
Exception Codes: 0x0000000000000001, 0x000000026f4ea2a7
VM Region Info: 0x26f4ea2a7 is not in any region.  Bytes after previous region:<PHONE_NUMBER>  Bytes before following region:<PHONE_NUMBER>7
      REGION TYPE                 START - END      [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      unused shlib __TEXT      21473c000-215220000 [ 10.9M] r--/r-- SM=COW  ... this process
--->  GAP OF 0xdaade0000 BYTES
      VM_ALLOCATE              fc0000000-1000000000 [  1.0G] ---/--- SM=COW

Thread 0 name:   Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   TextInputCore                 	       0x1af2df4e4 KB::String::iterator::operator--+ 62692 () + 132
1   TextInputCore                 	       0x1af2df478 KB::String::iterator::operator--+ 62584 () + 24
2   TextInputCore                 	       0x1af3b9f5c KB::String::find_last_of+ 958300 (KB::String const&, KB::String::iterator const&) const + 176
3   TextInputCore                 	       0x1af37f664 KB::String::find_last_of+ 718436 (KB::String const&) const + 96
4   TextInputCore                 	       0x1af37d8f0 TIInputManager::should_generate_candidates+ 710896 (KB::String const&, KB::String const&) const + 432
5   TextInputCore                 	       0x1af3e9818 -[TIKeyboardInputManager canTrimInputAtIndex:] + 220
6   TextInputCore                 	       0x1af3e8fb8 -[TIKeyboardInputManager trimInputAfterLathamConversion] + 208
7   TextInputCore                 	       0x1af3eed08 -[TIKeyboardInputManager textAccepted:fromPredictiveInputBar:withInput:] + 1804
8   TextInputCore                 	       0x1af331614 -[TIKeyboardInputManagerWrapper textAccepted:completionHandler:] + 288

Is https://developer.apple.com/forums/thread/690698 the only filing with Apple?  I haven't worked at Apple in over 15 years, but when I was there Radar was the only way to file bugs, I'm not sure if posting on developer forums would reach the actual engineers.  It looks like https://developer.apple.com/bug-reporting/ is the current process?

Thanks @eseidelGoogle yes this repo https://github.com/ThatchTravel/keyboard_crash has the smallest repro steps for this issue.
We have mostly seen the apple crash logs failing due to AutoCorrect AutoSuggest and Emoji keyboard usages, with the above kbd crashes.
Thank you for the bug reporting link, I have submitted this bug report on this link as well. FB9755382

Reproduced.  Cursor still blinks, but simulator doesn't respond to any clicks after it hangs (thus you can't change focus or dismiss the keyboard, etc.
The ABC switch keyboard button is disabled, but you can stills scroll the emoji keyboard back and forth in this hung state. Clicking on the emoji doesn't do anything.

I got it to hang a second time in the simulator (iPhone 13, iOS 15).  Flutter run is able to run it again, but the keyboard is still hung for the device after the app starts again from flutter run.
I've tried 4 times to get it to hang.  Both times when I was successful, I filled out the "Untitled" and "description" fields before adding text into the body.

Yeah, I'm able to reproduce consistently now, with very few keypresses.  kbb hangs.  I haven't yet seen it crash.

Sample of kbd.txt

eseidel-macpro% flutter doctor -v
[✓] Flutter (Channel master, 2.4.0-1.0.pre.94, on macOS 12.0.1 21A559 darwin-x64, locale en)
    • Flutter version 2.4.0-1.0.pre.94 at /Users/eseidel/src/flutter
    • Upstream repository https://github.com/eseidelGoogle/flutter.git
    • Framework revision ba143ae21e (4 months ago), 2021-07-06 22:01:02 -0700
    • Engine revision 60eea42346
    • Dart version 2.14.0 (build 2.14.0-284.0.dev)

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 13.1, Build version 13A1030d
    • CocoaPods version 1.10.1

[✓] VS Code (version 1.62.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.28.0

[✓] Connected device (3 available)
    • iPhone 13 (mobile) • 79C7C488-7701-44EE-99C4-8FB26C6159AB • ios            •
      com.apple.CoreSimulator.SimRuntime.iOS-15-0 (simulator)
    • macOS (desktop)    • macos                                • darwin-x64     • macOS 12.0.1 21A559 darwin-x64

• No issues found!

/cc @justinmc @LongCatIsLooong

I reduced the example a little further: https://github.com/eseidelGoogle/keyboard_crash
I updated my Flutter:
• Framework revision e0e8d28e0b (14 minutes ago), 2021-11-16 12:06:37 -0600
And I'm able to still repro (the hang at least, I've never seen it crash).

I think I'm done causing trouble here, sorry for all the bug mail.  Hopefully the infos above is useful.

OK.  I lied.  I had too much fun reducing, so I finished.  This is as small as I think I can get it.
If we decide that the constant rebuilds of the TextField are a bad thing, we should figure out why it's so easy to have Provider do that, and if we need to offer guidance to the provider package.
import 'package:flutter/material.dart';

// https://github.com/flutter/flutter/issues/90238
// Reproduction instructions
// Launch in iOS simulator
// Click on the top FormField, type "www😄😄😄", will require clicking on
// soft keyboard for ascii, switching to emoji, then clicking there.
// Click on the second field, type "www😄" and iOS keyboard will hang!

void main() async {
  runApp(MaterialApp(
    home: Scaffold(
      appBar: AppBar(),
      body: Column(
        children: [TextFormField(), const NodeItem()],
      ),
    ),
  ));
}

class NodeItem extends StatefulWidget {
  const NodeItem({
    Key? key,
  }) : super(key: key);

  @override
  State<NodeItem> createState() => _NodeItemState();
}

class _NodeItemState extends State<NodeItem> {
  // This text seems to be required, unclear why:
  late final controller = TextEditingController(text: '\u0000');

  @override
  Widget build(BuildContext context) {
    return TextField(
      controller: controller,
      // Originally Provider was causing the rebuilds, but this seem to
      // work too:
      onChanged: (_) => setState(() {}),
    );
  }
}

Here is a provider flavored reproduction:
https://github.com/eseidelGoogle/keyboard_crash/blob/8dff8c5097299a4beb3825d496b1694c994cbb46/lib/main.dart
which again, if we decide there is also a bug in provider (that it shouldn't make it so easy to constantly rebuild text fields), we should let them know. :)

@eseidelGoogle - any insights from the Flutter team on this? This is still aggressively affecting our users on our production app.

This issue is in a GitHub issue label black hole.  Added engine and framework labels since we don't know where the issue is, and @gaaclarke requested that someone from the framework team take a look.

@goderbauer this team is getting weird behaviors on iOS with TextEditingController.  I've reproduced it locally once and I can't conclusively tie it to anything Flutter is doing wrong (framework or engine) and it seems to be an apple bug since it is taking down the whole operating system.  I've worked with them to trim it down to small(ish) reproduction code.  Can someone on the framework team give it a quick glance to see if they are doing something obviously oddball that would lead them to see this behavior?

I spoke with a former engineer from the iOS Keyboard who happens to be a friend, and his feedback was basically "you'll really want a swift/obj-c example to get traction in Radar".  So that's a potential next step here.  Or for us to have one of our text-editing experts look at this and realize that no, in fact we're not intending to be constantly rebuilding the iOS keyboard state for example. :)

@rrousselGit (no action expected) may have thoughts on the provider-flavored reproduction.

Or for us to have one of our text-editing experts look at this and realize that no, in fact we're not intending to be constantly rebuilding the iOS keyboard state for example. :)

Yea, I'd like a sanity check that the reproduction code isn't doing something odd that just shuffling the code around and using the API as it was intended might resolve.  I know that's not an excuse for it to misbehave but when we are dealing with what appears to be an operating system bug it's a good first step.  Maybe @LongCatIsLooong would have a good idea?

Jumping on this~
I haven't read the entire thread so I may be missing some things but I'll try my best

If we decide that the constant rebuilds of the TextField are a bad thing,

That sounds like a bad idea. To me, that's clashing with the core rules of widgets. That is, how often a widget rebuilds should not have an impact on the behavior of the application (besides maybe a few skipped frames here and there)

if we decide there is also a bug in provider (that it shouldn't make it so easy to constantly rebuild text fields), we should let them know. :)

Provider "provides" (had to sorry!) all the tools necessary for reducing rebuilds.
Instead of:
return Consumer<BoardEditorViewModel>(
   builder: (context, node, child) {
     return TextField(
       controller: node.controller,
     );
   },
 );

you can do:
final controller = contexr.select<BoardEditorViewModel, TextEditingController>(
  (node) => node.controller,
);

return TextField(controller: controller);

This won't rebuild the TextField unless the controller changes (and it doesn't in the sample given, so it won't rebuild).

Thanks @rrousselGit trying to see if this helps in mitigating the actual issue in our repro repository.
Where exactly your above suggestion fits in our existing code:
https://github.com/ThatchTravel/keyboard_crash/blob/main/lib/src/editor/node_item.dart#L20 ?

You can call context.select as many times as you want to select multiple values
So:
TextField(
  autofocus: context.select((BoardEditorViewModel node) => node.focus.hasPrimaryFocus),
  focus: context.select((BoardEditorViewModel node) => node.focus),
  ...
)

Thanks @rrousselGit I tried your suggestion here:
https://github.com/ThatchTravel/keyboard_crash/blob/ahetawal/fix-try/lib/src/editor/node_item.dart#L19
But we are still able to repro the crash at this time.

What you did is not what I showed
Your "select" function should not return node.  It should return the properties within node that you use. You will have to call select multiple times for that
Also, you need to make sure that the widget isn't rebuilding for a different reason.
You may have to check the other widgets. It's possible that an ancestor of this widget is rebuilding, causing it to rebuild too.

Thanks @rrousselGit for your suggestions, (i think) I have it setup like you are referring it above now.
https://github.com/ThatchTravel/keyboard_crash/blob/ahetawal/fix-try/lib/src/editor/node_item.dart#L25
One thing I notice, I do see the node_item being build for all the nodes present, as I switch focus between different nodes or even if I select text in one node, all nodes are getting rebuild again.
So it seems the ancestor is rebuilding these, as from functional perspective we do want these updates based on our different focus and selection scenarios in one node which can affect other nodes as well.
Anything else I can try here ?

I used to work on a React Native app that incurred this issue strictly on simulators. It would go away for a while if we pressed Device > Erase All Contents and Settings in the Simulator app's menu bar.
Before that assignment I was a native iOS dev and this would sometimes happen with the simulator on relatively low dependency projects.

Is there any update regarding this issue. we are facing same issue in our app which is using web view. I am getting following error and app is being freezed.
-[UIKeyboardTaskQueue lockWhenReadyForMainThread] timeout waiting for task on queue
Keyboard queue task timeout detected


Update Changelog by release operation

Automated changes by create-pull-request GitHub action

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[entropy_src] Rework swread packer FIFO, reduce esfinal FIFO depth

This PR contains two separate commits to reduce the overall area footprint of ENTROPY_SRC by reducing the number of full 384-bit seeds buffered in the design:

The first commit reduces the depth of the esfinal FIFO from 4 to 3. This should not impact performance as the CSRNG instance connected to ENTROPY_SRC has 3 contexts. This means the esfinal FIFO has still enough space to have one seed ready per CSRNG instance.
The second commit reworks the swread packer FIFO to not buffer the seed readable by software. This works because whenever SW can read the final seeds, no entropy is forwarded to CSRNG anyway. This means, the seeds can directly read from the esfinal FIFO.

In total, this PR should reduce the area by around 768 FFs.
I've run the chip_sw_entropy_src_kat_test chip level test to explicitly verify the swread path still works (second commit) and a block-level regression with a reduced number of seeds is currently running. So far, the results look okay.

Update: the block-level regression looks fine. This can be merged once it's approved and CI ran through.


bug: remove topolvm node SCC

The SCC is not used in this moment.
If you try to install, kustomize produce an error because the file
is not present.
$ IMG=quay.io/sp1098/lvm-operator:latest  make deploy
...
failure on '/home/sapillai/go/src/github.com/red-hat-storage/lvm-operator/config/rbac/topolvm_node_scc.yaml' : lstat /home/sapillai/go/src/github.com/red-hat-storage/lvm-operator/config/rbac/topolvm_node_scc.yaml: no such file or directory, get: invalid source string: topolvm_node_scc.yaml\"\n\n

I will introduce a topolvm node SCC after testing it (wip).
Signed-off-by: Juan Miguel Olmo Martínez<EMAIL_ADDRESS>

resolved in:
https://github.com/red-hat-storage/lvm-operator/pull/32


Should fortran-lang.org provide reference to intrinsic modules?

See PR #344 in ford, and specifically this comment by @ZedThree:

The Fortran wiki is probably still the best place for the intrinsic
modules. fortran-lang.org looks shinier, but it doesn't seem to have
all the info the wiki does.

It seems that there is a visual appeal to fortran-lang.org, and it has higher search ranking than any other Fortran website. Though FortranWiki provides nice references, they're outdated. at least iso_fortran_env and iso_c_binding that I looked at are.
Should we provide references to these modules under https://fortran-lang.org/learn?
CC @certik @LKedward @awvwgk @jrblevin

Perhaps a new section Reference would be more suitable than Learn?
I've always missed something similar to https://en.cppreference.com/w/ or https://docs.python.org/3/. I've looked at their pages and setup before but unfortunately I lack the time or webpage skills to get something started.
Starting with the intrinsic modules would be a great way to get the ball rolling.

I imagined Reference would be a mini-book under Learn, but a separate page would work as well.

Yes, fortran-lang.org/reference would be perfect. An "official" (=community approved) reference to all intrinsic functions and language constructs in a searchable form. We definitely need that.

Fortran badly needs an equivalent to cppreference, including their compiler support page. There's something similar on Fortranwiki, but it uses data from the Fortran Forum which is "does the latest version of compiler support feature", as opposed to cppref's "in what version did compiler first support feature".
It might be useful to note that cppref is a wiki, but with a curated/managed structure.

@urbanjost has the full reference as man pages:

Discourse thread
Repository
Example reference website

Actually, I moved the fpm plugin to plugins.  The link above still works, but I deleted that repository a while ago, and last I remember that means it will actually vanish at some point. I had several things including the platform-independent plugin I wanted to try (particularly useful on MSWIndows which does not typically have the man(1) command unless installed via Cygwin or some form of Linux) and wanted to make a Fortran version of txt2man and so on, and was thinking that putting a group of the man-pages by category out each month on Fortran Discourse or Learn (or ...?) for  group comment/editing might be useful; have been planning on some time of migration to fortran-lang for something like a year and never quite had the time.  If what I have is a useful seed I am open to ideas on how to leverage it for this purpose. The way I have it now lets me just edit plain text and automatically convert it to the M_intrinsics module for use by the plugin and actual man-pages via txt2man(1) which are things I want and have set up (in a very singular way) as a push-button operation, including extracting and building all the example programs in the man pages and I did not want to loose that, but I think having at least the intrinsic descriptions sans vendor extensions (or explicitly marking them as such) is worth pursing and some of this shouldl be usable for that purpose.

Is this something I could help with? We need all this information online in a nice modern-looking format with syntax highlighting, links, maybe even diagrams if necessary. So, for that we'd have to abandon the man format. I could take a crack at converting it to markdown.
Note: FortranWiki and also the Gfortran docs are both GPL (GFDL) I believe. Is that something we want to avoid? Otherwise, we could incorporate some of that as well.

Oh I see now that @urbanjost's content is already GFDL since it is already based on those pages.

This is absolutely worth pursuing.
Regarding the license, I strongly recommend using BSD or MIT for the documentation also. The GFDL has number of issues:

https://en.wikipedia.org/wiki/GNU_Free_Documentation_License#Criticism.
https://wiki.debian.org/DFSGLicenses#GNU_Free_Documentation_License_.28GFDL.29

I would like to be able to include such documentation either with LFortran, or (even better) with our (future) VSCode extension where you point your cursor at an intrinsic, hit a button, and it will load documentation for it (locally, so that it can work offline).

The two main approaches would appear to be to make the documentation as nice as possible on the fortran-lang site and then see how to use it from a CLI environment, or to make it useable in a CLI environment and then place it as best as you can on fortran-lang.
In this case the approach was primarily the second.  The man-page format is a good one regardless for describing intrinsics, but not the best for providing a description of Fortran in general. But the structure of a man-page is good for describing procedures so
this was treated as a special case. Some of the considerations were
Each vendor supplies a browser-based www description of their intrinsics, but with the descriptions often conflated with their own extensions and/or not including functions they have not implemented yet. So there is room for a complete standard-based description of intrinsics on the web, but there are the mentioned alternatives, and they do include descriptions of extensions, which can be valuable even at the cost of portability.
The standard itself is the ultimate description, but is not easily available in a CLI environment and is written to be definitive at the cost of being clear and concise and it is a bit unclear on whether even the last draft can be reused without licensing issues.
All of the above rarely contain completely functioning example code.
manpages are still in extensive use and still heavily used by C developers, as well as by many other languages.
So since the route I took making M_intrinsics and the associated files deserves some explanation, here is some background:
manpages are already integrated into a good number of CLI tools; such as vim(1). For example, if editing Fortran code you can place your cursor on a word and hit a capital K and you will be taken to a man-page for that word.
*roff is still the language used to create a man-page (why on earth the man(1) command does not also support HTML is beyond me).
An ideal description could be included as block text in program comments, produce readable output for Ford and Doxygen, be used to generate a man page, be easily converted to HTML, be a simple flat-text or simple markup language that virtually anyone can write without learning *roff or LaTex and be accessible in any Fortran environment, and require little or no additional software installed to be used, and support whatever documentation standard emerges for describing fpm packages and stdlib.
The closest to flat text of any markup language is that provided by txt2man, so that man-pages literally look like flat text.  That format is relatively compatible with Ford/Doxygen just be adding a few comments.  So the prep(1) preprocessor allows you to create plain blocks of text that can be written to a file for processing via txt2man(1). Simultaneously it can convert the text to Fortran comments to document the code, and the comments can be massaged to work with Ford/Doxygen (prep(1) still needs some work along those lines).  Although not of the best quality, man-pages can be converted easily to HTML (and many other formats) and served on web servers via several commonly available packages. man-pages can be used on all GNU/Linux and Unix platforms as well as CygWIn.  Since info(1) can read man-pages and automatically produce cross-links to references like sin(1), and the HTML pages generated from man-pages can be used lynx/links/w3m in other CLI environments or by any browser
that covers a lot of group.
The intrinsic man-pages can then be written as txt2man input files for easy maintenance and then converted to manpages and bundled.  For environments without man(1) or info(1) (note mingw64 contains info(1) but not man(1). Not sure if info(1) can read man-pages if man(1) is not on the platform, but that was the original hope).
In addition, since txt2man(1) markup is a matter of context and indenting and whitespace and not special characters it can be used as flat text for a simple utility to display the text on any platform. Along those lines, to create such a utility that requires no other files the markdown files are converted to a format accessible from a Fortran program automatically -- (see the M_intrinsics module, available as an fpm(1) module).  An fpm(1) plugin utility (originally designed to be called directly by fpm(1), actually)  called fpm-man(1) can then be used to easily access the man-pages from ANY Fortran environment, albeit not (currently) with hyperlinks or color).  As long as a certain convention is followed that program can also extract the demo programs in the man-pages.
So:

the documents can be written in a nearly flat-text style.
This style can easily be learned and  included in Fortran code using a preprocessor. prep(1) already supports this, and it seems it would be easy to add to fypp(1) as well.
the documents can automatically be converted to man-pages; which is still the closest to a standard procedure and command description utility GNU/Linux and Unix has, and the current runner-up is info(1) which can display man-pages
tools such as vim(1) hook into man-pages
almost any GNU/Linux box or Unix box can automatically convert man-pages to HTML or PDF, albeit not of create quality; and HTML is the closest to a lingua-franca that I know of.
a program has been created to allow for displaying the flat-text versions in any Fortran environment, and incorporates an a plug-in to fpm(1).

So the main goals decided on where
There is a stronger need for documentation being available on a per-intrinsic basis in CLI environments than as a web document, but there is room for both.
There should be a basic CLI interface available in any environment that depends on little or no infrastructure that hooks into fpm(1) as a plug-in.
The man-page format is a good one for intrinsics that many people are familiar with even outside of the context of the man(1) command itself.
And of course, this format was already built into my own build process as a way to document my code (essentially everything I write has text blocks in them for documentation purposes (sometimes HTML or LaTex, but mostly txt2man input) that is run through prep(1) or it's big brothers, and I wanted to minimize the effort it would take me!

So I have my own programming environment, but this would let you roughly simulate it on a GNU/Linux box.
Assuming you have a directory called  "github" off your home directory and that the default directory $HOME/.local/ for your fpm(1) prefix is OK and that you have the directory $HOME/.local/pdq in your path, you can create a file anywhere with a Fortran
code in it that optionally goes through the prep(1) pre-processor if ending in the ".ff" suffix that has a manpage in it and uses your favorite fpm(1) packages  (as arbitrarily listed in the script, which would need customized) you can just say "ff filename.ff" and you
have comments in your code, and a txt2man(1) input file in $HOME/github/man that a simple script processes and creates a manpage and HTML document from.  So your code is documented, you have a manpage for the code, and an HTML version of the manpage built, and your code is built and installed in the test directory in your search path using your favorite fpm(1) dependencies.
This was the shortest I could find quickly. So I can write a program with a simple manpage in it as a plain text block, make calls to most POSIX routines via ISO_C_BINDING interfaces, and call a command-line argument parser and build and install my program in my path using fpm(1) like all of that was a standard part of Fortran with a single command. At some point I would like
us to add something like that via an fpm(1) plugin where stdlib supplies a lot of functions like that, but we need to standardize on how to call different preprocessors,  use fpm(1) as a package that has an API to the backend engine, and so on.  The "ff" script shown here is a kluge that needs customized by each user but is just for demonstration purposes. I know it is all possible because I have something similiar (ccall(1)) that I have used for years like it; and I can write a little utility in Fortran faster than I can in python or bash using it.
 se M_kracken, only : kracken, lget
use M_system, only : system_gethostname
implicit none
character(len=:),allocatable :: name
integer                      :: ierr
   call kracken('hostname','-help .F. -version .F.')
   call help_usage(lget('hostname_help'))
   call help_version(lget('hostname_version'))
   call system_gethostname(name,ierr)
   write(*,'(a)')name
contains
$BLOCK HELP -file _hostname.1.man
NAME
    _hostname(1f) - [FUNIX] display hostname
    (LICENSE:PD)
SYNTAX
    _hostname [ -help|-version]
DESCRIPTION
    Calls system_gethostname(3f), which calls get_hostname(3c) to determine
    the current host name.
OPTIONS
       --help     display this help and exit
       --version  output version information and exit
EXAMPLE
   Sample execution:

    >_hostname
    >buzz
$BLOCK END
$!@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
$BLOCK VERSION
PRODUCT:        GPF (General Purpose Fortran) utilities and examples
PROGRAM:        _hostname(1f)
DESCRIPTION:    print hostname
VERSION:        1.0, 2016-12-01
AUTHOR:         John S. Urban
REPORTING BUGS: http://www.urbanjost.altervista.org/
HOME PAGE:      http://www.urbanjost.altervista.org/index.html
LICENSE:        Public Domain. This is free software: you are free to change and redistribute it.
                There is NO WARRANTY, to the extent permitted by law.
$BLOCK END
end program demo_system_gethostname

#!/bin/bash
#@(#) given a source file for a program build it with preprocessing via prep(1) default list of packages and install

###############################################################################
export FF_DIR=$HOME/github/ff_cache
export PREFIX=$HOME/.local
export BINDIR=pdq
export PREP_DOCUMENT_DIR=${PREP_DOCUMENT_DIR:-$HOME/github}
#export PREP_COMMENT_STYLE=ford
###############################################################################
SHORT(){
case "${1}" in
 *.f90) SHORTNAME=$(basename $1 .f90) ;;
 *.ff)  SHORTNAME=$(basename $1 .ff)  ;;
 *.FF)  SHORTNAME=$(basename $1 .FF)  ;;
 *.F90) SHORTNAME=$(basename $1 .F90) ;;
 *.c)   SHORTNAME=$(basename $1 .c)   ;;
 *)     SHORTNAME=$(basename $1) ;;
esac
}
###############################################################################
NEWTOML(){
cat >$FF_DIR/fpm.toml <<EOF
# TOML file for fpm as described at https://github.com/fortran-lang/fpm/blob/master/manifest-reference.md
name = "fpm_cache"
version = "0.1.0"
license = "MIT"
author = "John S. Urban"
maintainer =<EMAIL_ADDRESS>copyright = "2020 John S. Urban"
description = "compiled by fpm(1)"
categories = ["General Purpose Fortran"]
keywords = ["fortran", "fpm" ]
homepage = "https://github.com/urbanjost"

[install]
#library="false"
library=false

# this is used because changing the package name causes a rebuild of dependencies
# and editing or replacement of the build/cache.toml file
[[executable]]
name="$SHORTNAME"
source-dir="app"
main="$MAIN"

[dependencies]
M_args        =  {  git  =  "https://github.com/urbanjost/M_args.git"        }
M_CLI2        =  {  git  =  "https://github.com/urbanjost/M_CLI2.git"        }
M_CLI         =  {  git  =  "https://github.com/urbanjost/M_CLI.git"         }
M_kracken95   =  {  git  =  "https://github.com/urbanjost/M_kracken95.git"   }
M_kracken     =  {  git  =  "https://github.com/urbanjost/M_kracken.git"     }

M_draw        =  {  git  =  "https://github.com/urbanjost/M_draw.git"        }
M_history     =  {  git  =  "https://github.com/urbanjost/M_history.git"     }
#M_intrinsics  =  {  git  =  "https://github.com/urbanjost/M_intrinsics.git"  }
M_io          =  {  git  =  "https://github.com/urbanjost/M_io.git"          }
M_LA          =  {  git  =  "https://github.com/urbanjost/M_LA.git"          }
M_list        =  {  git  =  "https://github.com/urbanjost/M_list.git"        }
M_msg         =  {  git  =  "https://github.com/urbanjost/M_msg.git"         }
M_process     =  {  git  =  "https://github.com/urbanjost/M_process.git"     }
M_sort        =  {  git  =  "https://github.com/urbanjost/M_sort.git"        }
M_strings     =  {  git  =  "https://github.com/urbanjost/M_strings.git"     }
M_system      =  {  git  =  "https://github.com/urbanjost/M_system.git"      }
M_time        =  {  git  =  "https://github.com/urbanjost/M_time.git"        }

#M_messages    =  {  git  =  "https://github.com/urbanjost/M_messages.git"    }
#M_stopwatch   =  {  git  =  "https://github.com/urbanjost/M_stopwatch.git"   }
#M_random      =  {  git  =  "https://github.com/urbanjost/M_random.git"      }
#M_math        =  {  git  =  "https://github.com/urbanjost/M_math.git"        }
#M_regex       =  {  git  =  "https://github.com/urbanjost/M_regex.git"       }
EOF
}
################################################################################
DISPLAY(){
cat <<EOF
================================================================================
   NAME       $NAME
   SHORTNAME  $SHORTNAME
   MAIN       $MAIN
   TOML       $(grep $SHORTNAME $FF_DIR/fpm.toml|xargs)
   INSTALL    fpm install $OPTS --prefix $PREFIX --bindir $BINDIR --verbose
   OPTS       $OPTS
================================================================================
tree $FF_DIR
#read PAWS
EOF
}
################################################################################
DISPLAY(){
cat <<EOF
================================================================================
   NAME       $NAME
   INSTALL    fpm install $OPTS --prefix $PREFIX --bindir $BINDIR --verbose
================================================================================
tree $FF_DIR
#read PAWS
EOF
}
################################################################################
NAMES=''
OPTS=''
for NAME in $*
do
if [ -e $NAME ]
then
   NAMES="$NAME $NAMES"
else
   OPTS="$OPTS $NAME"
fi
################################################################################
done
case "$OPTS" in
*-profile*);;
*) OPTS="$OPTS --profile release" ;;
esac
################################################################################
for NAME in $NAMES
do
   SHORT $NAME
   if [ ! -d $FF_DIR ]
   then
      fpm new -app $FF_DIR
      rm $FF_DIR/app/main.f90
   fi
   case "$NAME" in
   *.ff)  MAIN=$SHORTNAME.f90;prep -D TESTPRG90 -i $NAME -o $FF_DIR/app/$MAIN;;
   *.FF)  MAIN=$SHORTNAME.F90;prep -D TESTPRG90 -i $NAME -o $FF_DIR/app/$MAIN -system;;
   *.F90) MAIN=$SHORTNAME.F90;cp $NAME $FF_DIR/app/$MAIN;;
   *.f90) MAIN=$SHORTNAME.f90;cp $NAME $FF_DIR/app/$MAIN;;
   *.c)   MAIN=$SHORTNAME.c;cp $NAME $FF_DIR/app/$MAIN;;
   esac
   if  test ! -f "$FF_DIR/app/$MAIN"
   then
      echo file "<ERROR> $FF_DIR/app/$MAIN is not a file"
   fi
   if  test ! -s "$FF_DIR/app/$MAIN"
   then
      echo file "<ERROR> $FF_DIR/app/$MAIN has no length"
   fi
   NEWTOML
   DISPLAY
   (
      cd $FF_DIR
      fpm install $OPTS --prefix $PREFIX --bindir $BINDIR --verbose
      rm $FF_DIR/app/$MAIN
      rm -f $FF_DIR/app/*
   )
done
################################################################################
exit
################################################################################

This has been resolved with the intrinsic documentation in the learn section


operator project-quay (3.10.0-nightly.20230817)

Add 3.10.0-nightly.20230817 to community operators

/merge possible

/merge possible


chore(starknet_integration_tests): use ContractClassesMap to prepare state

This change is

#2488  👈 (View in Graphite)
main

This stack of pull requests is managed by Graphite. Learn more about stacking.


Override Span Writes in PagedBufferedTextWriter

Please override Span Writes in PagedBufferedTextWriter, default implementations on TextWriter is using ArrayPool for temp array.
I propose to add such a method in PagedCharBuffer and use it in PagedBufferedTextWriter
        public void Append(ReadOnlySpan<char> buffer)
        {
            if (buffer.Length > 0)
            {
                var index = 0;
                var count = buffer.Length;

                while (count > 0)
                {
                    var page = GetCurrentPage();
                    var copyLength = Math.Min(count, page.Length - _charIndex);

                    buffer
                        .Slice(index, copyLength)
                        .CopyTo(new Span<char>(page, _charIndex, copyLength));

                    _charIndex += copyLength;
                    index += copyLength;
                    count -= copyLength;
                }
            }
        }

PagedBufferedTextWriter passes to custom IHtmlContent implementations

The type's internal and it's unlikely we'd continue using it when working with BodyPipe. The recommendation would be to copy the file to your application and modify it as you see fit.

@pranavkm, I do not understand, this is mvc views area, not servers.
Why should I copy it into my application? I and others uses IHtmlConent for custom Html helpers in views, and current implementation are not great


Add how to using PT links in readme and support

Summary of the Pull Request
What is this about:
adding in links a bit more
What is include in the PR:
pure text updates
How does someone test / validate:
Quality Checklist

[ ] Linked issue: #https://github.com/microsoft/PowerToys/issues/13025
[ ] Communication: I've discussed this with core contributors in the issue.
[ ] Tests: Added/updated and all pass
[ ] Installer: Added/updated and all pass
[ ] Localization: All end user facing strings can be localized
[ ] Docs: Added/ updated
[ ] Binaries: Any new files are added to WXS / YML

[ ] No new binaries
[ ] YML for signing for new binaries
[ ] WXS for installer for new binaries

Contributor License Agreement (CLA)
A CLA must be signed. If not, go over here and sign the CLA.

@crutkas
Is the aka link for docs a new link? If yes we should uodate settings ux and tray menu.

@htcfreek As you can see in this document this link isn't new.


updated remediate role link

Updated remediate link in readme to updated name.
Signed-off-by: George Nalen<EMAIL_ADDRESS>

supersceded with #5


:sparkles: Export/Import Assessments.

Update export/import to support assessments.
This is needed for migrating assessments from PathFinder to the Hub in tackle 0.3.
Prerequisite: Legacy Pathfinder questionnaire must be seeded.
The Pathfinder API offers an endpoint for retrieving assessments by application ID. This is accesssible from the Hub (pre-Custom Assessments) at /pathfinder/assessments?applicationId=<id>
An original Pathfinder assessment is described by these data structures. Comments indicate some of the fields that have different names in the new data model.:
type LegacyAssessment struct {
    ID uint
    ApplicationID uint
    Status string
    Stakeholders []uint
    StakeholderGroups []uint
    Questionnaire Questionnaire
}

type Questionnaire struct {
    Categories []Category
    Title string // Corresponds to `Name` in the new model.
}

//
// Category corresponds to `Section` in the new data model.
type Category struct {
    ID uint // ignored
    Order uint
    Title string // corresponds to Section.Name
    Questions []Question
    Comment string // ignored
}

type Question struct {
    ID uint // ignored
    Order uint
    Question string // corresponds to Text
    Description string // corresponds to Explanation
    Options []Option
}

type Option struct {
    ID uint // ignored
    Order uint
    Option string // corresponds to Text
    Checked bool // corresponds to Selected
    Risk string // one-of RED,AMBER,GREEN,UNKNOWN (replaced by red,yellow,green,unknown in new model)
}

For each application, any assessment will have to be retrieved, converted to match the new Assessment API resource, and posted to the upgraded Hub with the Assessment's Questionnaire ref pointing to the seeded legacy questionnaire (ID 1).

Looks good, thanks for providing description 👍


Rename interactors & fix packages

Closes #81
Readable Readme: https://github.com/thefuntasty/mvvm-android/blob/feature/rename-interactors/README.md

          2 Warnings

:warning:
This pull request is too big.

:warning:
Please start subject with capital letter.
39f534deeb04f9f130508f1651d31cebd007a925

  Generated by :no_entry_sign: Danger