Q:

How to get the name of the nearest interactive ancestor shell from a script?

I know that one can use the $- contains i or not or check if $PS1 is empty to tell if a shell is interactive.
However, those solutions only work for the current shell.
I have a bash script trying to find the immediate parent shell that is interactive.
For example:

interactive shell: zsh
bash script 1 which executes bash script 2
bash script 2 contains the mechanism to find out the immediate interactive shell

So when we execute bash script 1 under our interactive shell zsh, we expects an output of zsh.
I cannot figure out how I can do it, when the script is running in the sub-shell.
Note
I want the script to be executed, not sourced.
Clarify

I have a bash script trying to find the first ancestor shell that is
  interactive.

By first ancestor, I meant that the first interactive shell we encounter during the bottom-up process-chain scanning process.
For example, in the case of: zsh(first interactive shell) -> bash(second interactive shell) -> bash(batch shell for script 1) -> bash(batch shell for script 2), we want to output bash(the second interactive shell).

A:

This is a really weird requirement. Why would you care what interactive shell invoked your script, or invoked some other program that isn't an interactive shell which in turn invoked your script? This has a very strong smell of a XY problem.
IF you really need to know, you can try to figure it out, but I don't think there's a fully reliable method, just one that works in typical cases.
Starting from $PPID, trace your script's ancestor processes (ps -o ppid= -p $ancestor_pid) until you either find the one that you're looking for, or one that indicates you've gone too far.
A simple strategy is to look for a process in a different process group (ps -o pgid= -p $ancestor_pid). Under normal circumstances, if your script was invoked by (a script that was invoked by) an interactive shell, that process you've reached is a shell with job control, which ran your script('s parent script) in a separate process group.
Here are some examples of things that can go wrong with this strategy:

One of the processes on that chain is already dead.
Your script was not invoked through an interactive shell, but through a cron job, from an X11 program, etc.

You may or may not want check that this process's standard input, standard output and standard error (e.g. with lsof, or via /proc if you don't need portability beyond Linux) are the same terminal as your script. It depends how you want to handle cases such as
bash$ xterm -e your_script

